: in normal mode takes me to the command line and displays the last command. However the : is highlighted in red and it is apparently impossible to edit the command. I read somewhere that the Kakoune command line uses the readline edit commands so I tried ctrl + e, ctrl + f etc. Then after many retyped commands I stumbled on up arrow to scroll the command history and eventually realized that one single up arrow releases the read highlight and the readline edit commands and other edit keys then work as advertised and expected.
The red : still allows me to hit enter to execute the command. What is the point of the red colon other than to require a possibly superfluous up arrow?
the great thing about up-arrow in prompt is that it uses prefix search, so it’s quite easy to retrieve past commands.
if you just press : it will show the very last command as autosuggestion. Maybe we can reduce the opacity of this autosuggestion to communicate it’s not editable (yet).
other than to require a possibly superfluous up arrow?
If you don’t want to retrieve a previous command but type a new one, then the up arrow behavior would be wrong. We could make : immediately insert the most recent command as editable text, and delete it automatically if the user starts typing another command. But this seems too complex (what if they use backspace etc.) so I’d say the current behavior is fine here.
The fact that the colon is red I think has been reported before, I think it was an accident.
So far as I can tell, the red colon means “you have not yet typed a complete command”.
When I press :, the : prompt is red, and I haven’t typed anything.
If I then type e, the prompt becomes black, since e is a known alias.
After typing c and h, the prompt is red again, since ec and ech are not commands or aliases.
After typing o, the prompt becomes black again, since echo is a known command.
The error-checking doesn’t appear to be any deeper than that - Kakoune knows what the valid flags for the :echo command are, but if I type :echo -xxxx (an invalid flag) the prompt does not become red, even though trying to execute that command produces an error.
The invalid command warning makes sense. However : gives the red colon and the prior command which is usually valid. I routinely successfully execute valid commands flagged with the red colon. up arrow clears the red :, down arrow reinstates the red. So red : may also be flagging scrolling past the end of the buffer. I think plain : should not create a scrolling error state.
It would be helpful to have a message indicating what type of error situation you are in at the command prompt: invalid command, out of range on the command buffer etc
up and down arrows are not readline key combinations although I’m not complaining. ctrl+p and ctrl+n do scroll the command history as per readline. ctrl+r brings up a register menu instead of searching history which is a separate issue.
yes definitely want access to the command history and I think I want the last command preloaded because in my (short) experience I’m executing the same commands repeatedly, typically :w or :source to date.
in case of wanting to start a new command perhaps ctrl+n aka down arrow could scroll past the end of the command buffer history and present an empty command line with an informational message instead of a red colon.
p.s. ctrl+n on the command line presents an empty line instead of an error message when reaching the end of the history buffer
p.p.s perhaps an optional numeric argument to : to indicate the command history scroll position. 0: could bring up an empty command line 1: would be the default and the current behavior. Unfortunately I can’t enter a zero quantifier…
p.p.p.s how about an informational message that tells you where you are in the command buffer history where 0 of 25 means 25 lines and you are past the most recent line, 26 of 25 means you are past the oldest line of history either on the command prompt or in a popup? this could allow the red : to focus on command errors…
p.p.p.p.s the current behaviour is exactly as you suggest. typing at the command prompt will over-write the auto-filled history command - which increased my golf score with Kakoune before I figured out up arrow
no red : when trying to up arrow past the oldest command in the history. That’s inconsistent in my books. I think an empty command line with a message to indicate past oldest history would be better
I reproduce the behaviour with :echo -xxx. at - the prompt for the valid options appears and it’s possible to tab through them. As you say selecting something off the list results in no red :.
echo %sh{ echo results in the command prompt incorrectly highlighting the kakoune echo command instead of the shell echo command… I can understand that the command line syntax is tough to casually parse character by character but perhaps there is room for improvement.
the tab list completion list for “echo -” includes - resulting in echo – if selected. on a bash command line echo – produces --, but nothing on kakoune. I’m curious if the - is a bug or there is some legitimate use for kakoune echo –
Lots of edge cases around the command prompt. Fortunately, haven’t hit any edges like this in normal mode
search (/) and pipe (|) also require arrow up or ctrl+p to enable edit of any prefilled command history. Probably applies to any line edit. The code for this appears to be in input_handler.cc and appears to handle ctrl(‘p’) (up arrow) the same for any type of line edit.
Added 2023-11-30
/ also starts with an error condition in that the search suggestions appear to match an empty search, not the prefilled search string that appears on the command line