-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Proposal for shipping 1.0 #6
base: main
Are you sure you want to change the base?
Conversation
Rendered view for those who need/want it |
I see this in the list: Use another function to mean "send value to pipeline". I’ve wondered whether that could be implicit for any pipeline that begins with an expression instead of a command. For example, $someVar | where ... | sort-by ... | ... A key thing to consider is whether anything else could be expected by starting a pipeline with an expression rather than |
I would love to have case-insensitive completions, particular for case-insensitive systems like Windows. For instance, if my current working directory has a sub-directory called "Documents" (capital "D"), then both This would ease the pain of moving from PowerShell to Nushell. Even if case-insensitivity were not the default, having the option to enable it via configuration would be fantastic. |
I would love to see better railguards against accidentally and permamently deleting files. See more discussion about this in this Reddit thread (where I'm |
@ehdevries It's a useful feature even on case-sensitive systems, I have case-insensitive tab-completions enabled in ZSH and it's such a help. This would be a huge quality-of-life option. |
@ehdevries @OvermindDL1 I’m not sure if this still works, but I have this working in an older version of nu with the following config
|
@jonstodle That did the trick for me! I'm using the latest version, 0.29, so that config is still valid. Thank you for the tip! With that in place, the only thing left would be to add this to the Nu Book's section on configuration. Update - issue to document this setting: nushell/nushell.github.io#116 |
One thing that I feel is missing from the RFC is integration with outside world. To ensure smooth operation with non-nushell tools.
In my case, both the |
I think it would be nice if a 1.0 release identified some kernel of critical features and invariants, and included a set of tests to demonstrate that nu is well behaved with respect to those. I ran into the behavior described in #3116 (should be fixed in #3278) which I think is fairly serious and seems to be caused by something which would have been relatively easy to smoke out using that approach. I completely understand that developers on projects like nu face very real time and resource constraints, but I think potential users would be less hesitant to adopt something as important as a new shell if they had some assurance that it won't do things like permanently delete things on accident, or if they at least knew the developers had this kind of safety in mind. Thanks for the hard work. |
Seeing https://determinate.systems/posts/nuenv (experiment to use nushell instead of bash for building software in nixpkgs), it seems there's a real demand for 1.0 now |
This adds the proposed plan for the upcoming releases which aligns us with a 1.0 release as part of our on-going work on Nushell.
The 1.0 release will be seen as an important milestone in Nushell's continued development, so we want to shape how it lands to give it a good chance of success and meeting the needs for both existing and future Nushell users.
We'd love to hear your feedback to help us refine and revise this proposal.