We split off the evaluation engine part of nu-cli into its own crate. This helps improve build times for nu-cli by 17% in my tests. It also helps us see a bit better what's the core engine portion vs the part specific to the interactive CLI piece.
There's more than can be done here, but I think it's a good start in the right direction.
* Begin allowing comments and multiline scripts.
* clippy
* Finish moving to groups. Test pass
* Keep going
* WIP
* WIP
* BROKEN WIP
* WIP
* WIP
* Fix more tests
* WIP: alias starts working
* Broken WIP
* Broken WIP
* Variables begin to work
* captures start working
* A little better but needs fixed scope
* Shorthand env setting
* Update main merge
* Broken WIP
* WIP
* custom command parsing
* Custom commands start working
* Fix coloring and parsing of block
* Almost there
* Add some tests
* Add more param types
* Bump version
* Fix benchmark
* Fix stuff
* Remove completion code from help/value shells
* Tweak the `Completer` trait for nushell.
Previously, this trait was built around rustyline's completion traits, and for
`Shell` instances. Now it is built for individual completers inside of nushell
that will complete a specific location based on a partial string. For example,
for completing a partially typed command in the command position.
Although convenient, since the user doesn't have to type the space, it could be
a little surprising to users since they may think that was the only completion
in certain completions modes (for example, `cycle`).
Previously, we used rustyline's filename completer. This allowed us to make
progress on the completion engine without building all the parts at once. We now
need our own filename completer to make progress.
The primary driver to having our own filename completer is that it can better
integrate with our path constructs. For example, if we have
> ls .../<TAB>
we want to show a list of suggestions that includes all files two directories up
from the current working directory. The least jarring experience to a user would
be to maintain the three dots. The easiest way for us to do this is by building
our own completer and path constructs.
* Show directories and executable for command completion.
Previously we chose from two sets for completing the command position:
1. internal commands, and
2. executables relative to the PATH environment variable.
We now also show directories/executables that match the relative/absolute path
that has been partially typed.
* Fix for Windows
The completion engine maps completion locations to spans on a line, which
indicate whther to complete a command name, flag name, argument, and so on.
Initial implementation is simplistic, with some rough edges, since it relies
heavily on the parser's interpretation. For example
du -
if asking for completions, `-` is considered a positional argument by the
parser, but the user is likely looking for a flag. These scenarios will be
addressed in a series of progressive enhancements to the engine.
