* Add rest arg to def
This commit applied adds the ability to define the rest parameter of a def
command. It does not implement the functionality to expand the rest argument in
a user defined def function.
The rest argument has to be exactly worded "...rest".
Example after this PR is applied:
file test.nu
```shell
def my_command [
...rest:int # My rest arg
] {
echo 1 2 3
}
```
```shell
> source test.nu
> my_command -h
Usage:
> my_command ...args {flags}
Parameters:
...args: My rest arg
Flags:
-h, --help: Display this help message
```
* Fix space in help on wrong side
* Remove wrong test case
* Parse long and shortflags without space correctly
* Update param_flag_list.rs
* Update param_flag_list.rs
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
* move commands, futures.rs, script.rs, utils
* move over maybe_print_errors
* add nu_command crate references to nu_cli
* in commands.rs open up to pub mod from pub(crate)
* nu-cli, nu-command, and nu tests are now passing
* cargo fmt
* clean up nu-cli/src/prelude.rs
* code cleanup
* for some reason lex.rs was not formatted, may be causing my error
* remove mod completion from lib.rs which was not being used along with quickcheck macros
* add in allow unused imports
* comment out one failing external test; comment out one failing internal test
* revert commenting out failing tests; something else might be going on; someone with a windows machine should check and see what is going on with these failing windows tests
* Update Cargo.toml
Extend the optional features to nu-command
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
* Put parse_definition related funcs into own module
* Add failing lexer test
* Implement Parsing of definition signature
This commit applied changes how the signature of a function is parsed. Before
there was a little bit of "quick-and-dirty" string-matching/parsing involved.
Now, a signature is a little bit more properly parsed.
The grammar of a definition signature understood by these parsing-functions is
as follows:
`[ (parameter | flag | <eol>)* ]`
where
parameter is:
`name (<:> type)? (<,> | <eol> | (#Comment <eol>))?`
flag is:
`--name (-shortform)? (<:> type)? (<,> | <eol> | (#Comment <eol>))?`
(Note: After the last item no <,> has to come.)
Note: It is now possible to pass comments to flags and parameters
Example:
[
d:int # The required d parameter
--x (-x):string # The all powerful x flag
--y (-y):int # The accompanying y flag
]
(Sadly there seems to be a bug (Or is this expected behaviour?) in the lexer, because of which `--x(-x)` would
be treated as one baseline token and is therefore not correctly recognized as 2. For
now a space has to be inserted)
During the implementation of the module, 2 question arose:
Should flag/parameter names be allowed to be type names?
Example case:
```shell
def f [ string ] { echo $string }
```
Currently an error is thrown
* Fix clippy lints
* Remove wrong comment
* Add spacing
* Add Cargo.lock
* move basic_shell_manager to nu-engine
* move basic_evaluation_context to nu-engine
* fix failing test in feature which commands/classified/external.rs
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.
* Obay precedence rules in which; Fix#2875
Before which did not obay the precedence of alias before def commands.
Furthermore, `which -a echo` would only report either an alias or a def command or an
internal command with the provided name. Not all.
With this commit applied its fixed :)
Example:
```shell
/home/leo/repos/nushell(fix/which_reports_wrong_usage)> def echo [] {^echo hi}
/home/leo/repos/nushell(fix/which_reports_wrong_usage)> echo
hi
/home/leo/repos/nushell(fix/which_reports_wrong_usage)> which -a echo
───┬──────┬──────────────────────────┬─────────
# │ arg │ path │ builtin
───┼──────┼──────────────────────────┼─────────
0 │ echo │ Nushell custom command │ No
1 │ echo │ Nushell built-in command │ Yes
2 │ echo │ /usr/bin/echo │ No
───┴──────┴──────────────────────────┴─────────
/home/leo/repos/nushell(fix/which_reports_wrong_usage)> alias echo = ^echo hi there
/home/leo/repos/nushell(fix/which_reports_wrong_usage)> echo
hi there
/home/leo/repos/nushell(fix/which_reports_wrong_usage)> which -a echo
───┬──────┬──────────────────────────┬─────────
# │ arg │ path │ builtin
───┼──────┼──────────────────────────┼─────────
0 │ echo │ Nushell alias │ No
1 │ echo │ Nushell custom command │ No
2 │ echo │ Nushell built-in command │ Yes
3 │ echo │ /usr/bin/echo │ No
───┴──────┴──────────────────────────┴─────────
```
* Fix clippy lint
* Fix vec always Some even if empty
This commit applied adds comments preceding a command to the LiteCommands new
field `comments`.
This can be usefull for example when defining a function with `def`. Nushell
could pick up the comments and display them when the user types `help my_def_func`.
Example
```shell
def my_echo [arg] { echo $arg }
```
The LiteCommand def will now contain the comments `My echo` and `It's much
better :)`.
The comment is not associated with the next command if there is a (or multiple) newline
between them.
Example
```shell
echo 42
```
This new functionality is similar to DocStrings. One might introduce a special
notation for such DocStrings, so that the parser can differentiate better
between discardable comments and usefull documentation.
