It can be reproduced with any command with menu completions running the development version of Kakoune. Say, for instance, I type buffer in the prompt. Now it lists all the current buffers, and the first one in the list is selected in the menu, albeit not filled in the prompt.
If I then press <ret> without explicitly selecting an entry, an exception is raised:
1:1: 'buffer' wrong argument count
Previously, pressing <ret> would automatically fill the buffer command's argument list with the first item in the menu. Now, this behaviour is only achieved if:
<tab>, effectively filling the prompt with the first menu entry;d to select the *debug* buffer and pressing <ret>; I don't need to write the entire name, just one letter is enough.I would like to have the previous behaviour restored, otherwise I'll need an extra keystroke every time I want to select the first entry in the menu, and I do it quite often.
Argh, thats right, its a side effect of the changes I introduced to auto-select the command on <space>. This needs to be fixed.
Nice to hear it will be eventually addressed. Thanks!
I took a look and its a bit tricky because int conflicts with the ability to validate an empty prompt to use the "default command" feature. In order to make that work now that the command-name completion has the menu flag, I needed to disable auto-insertion of the best completion when the current token is empty.
A workaround would be to change that logic to disable it only when the full command line is empty, but this is not sufficient because we get another undesirable behaiour: a <space> after ; inserts the new command name now that <space> also triggers menu completion auto-insertion.
We can the fix that by having a different behaviour on <space> and <ret>: <space> only inserts if the token is non-empty, <ret> only inserts if the prompt is non-empty. This seems to fulfill all requirements at the price of being a bit more complex. It might be a bit suprising as well as it will force insert a command after ; on <ret> but not <space>, I imagine this is not something that happens much in practice.
I guess we can go with that behaviour for now and if it proves to be hard to predict/explain we could then revisit it.
I think it's a nice solution. Thanks again!
@mawww :open_mouth:
I noticed something bad about that change. We cannot :<c-r>.<ret> without executing the first suggested command, in my case add-highlighter.
echo sh -c %{
echo "$@"
} -- a b c
Try selecting that string and :<c-r>.<ret>. The command will be executed, but because of the trailing newline, it will suggest the first candidate and execute add-highlighter.
Ouch, yeah thats a bad one, I think the best course of action is then to go back to the previous behaviour and accept that we need to <tab> once to get the first selected entry if we dont write anything for that argument.
I think I found an approach that should solve all problems, by making some completion tagged as "dont insert if empty" and tagging command names with it.
@mawww I experimented another issue.
Enter:
set-option global readonly true
Press : then Up to bring the last command. If I want to prepend unset, it will validate the first candidate.
un鈻宻et-option global readonly
In my case, it will execute:
unalias鈻宻et-option
Another drawback: it's hard to run a hidden command like :lsp-enable when it's a prefix of a non-hidden command, like :lsp-enable-window.
Also when typing :lsp-enable the docstring of lsp-enable is shown, but on Enter, lsp-enable-window is executed.
The point of hidden command is that they are not expected to be used interactively, so I am not too concerned about that issue, you can bypass the completion mechanism by quoting: :'lsp-enable'<ret> should make it possible to call lsp-enable from the prompt.