You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because bonzai makes it so easy to add subcommands, command name and
arguments conflicts are more probable. I suggest that we some parsing
logic that looks for an identifier that demarcates the end of the
command and start of arguments. This way any conflicts can be avoided.
The case I ran into this is with my note tool having an edit command
and variadic arguments. As the arguments can be any english word, it
would've clashed with the edit command.
The text was updated successfully, but these errors were encountered:
I'm not convinced this can't be avoided by avoiding default commands. I'm not inclined to violate "all command lines are speakable" for this. We had a similar situation before with things like help, that can also be arguments so we "burn" one valid argument for the sake of having it have special meaning. I'm open to discussing it, but pretty against it at this point.
My note command is completely in line with the "speakable command lines" idea. I avoid using quotes unless necessary for "noting" the test. For example
$ note this is a very import thought I want to capture. no need to use quotes for all of this to be captured
$ note todo "this is a case that requires quotes because the ? mark can't be used without quotes or escapes"
$ note edit this or that. this case represent the problem I am having with the current impl of bonzai, edit is also a subcommand to open editor, this will do that instead of capturing text
Above examples are valid commands using my note tool. here is where I would need a -- to differentiate between the "edit" as an argument vs as a command.
Because bonzai makes it so easy to add subcommands, command name and
arguments conflicts are more probable. I suggest that we some parsing
logic that looks for an identifier that demarcates the end of the
command and start of arguments. This way any conflicts can be avoided.
The case I ran into this is with my note tool having an
edit
commandand variadic arguments. As the arguments can be any english word, it
would've clashed with the
edit
command.The text was updated successfully, but these errors were encountered: