Kakoune: Allow Ctrl+C to quit command line mode

[kurkale6ka]

I've got an habit in Vim to quit the command line with Ctrl+C.
It'd be nice to have the same in kakoune, in addition to <esc>

[mawww]

<c-c> is already bound to sending SIGINT to kakoune process group (same as what it does in the shell), thats pretty nice to stop a shell script taking too long. It seems to make sense to have that work in insert mode as well, to be able to kill a badly written hook that takes too long.

Its actually a key thats handled a bit specially, as we have to handle it even in cases where user input is disabled (like when we are waiting for a shell command output). So I am not even sure its mappable.

Note that <esc> == <c-[> in all terminals.

[mawww]

I dont think this will change, Ctrl+c is very important as a way to kill eventual child processes, as Kakoune relies a lot on them.

[sanbor]

I confess that I also have the habit of using Ctr+C instead of <esc> in Vim. My two cents in this thread is that the statement "Ctrl+c is very important as a way to kill eventual child processes" should not affect using Ctr+C to exit edit mode. If there is a child process running, I think it is great to press Ctrl+C to kill it. But if I'm in edit mode and there are no child process running, it would be great if Ctrl+C will go to normal mode. Right now Ctrl+C doesn't do anything in edit mode.

I know it is annoying to add this feature but it would make kakoune more "Vim compatible" for some users.

Thanks for the <c-[> tip, I didn't know it!

[xtian]

I would also like to map \ to \ in insert mode as that's what I've been using in vim for a long time.

[c-dinkel]

It is a bit of muscle memory I cannot get rid of. ESC is too far away to be comfy. Same for [ on my dvorak keyboard. <c-c> hits just the spot :-)

[c-dinkel]

@mawww is there any way you might reconsider closing this issue? Would @sanbor 's idea be an acceptable solution for you? If so, should I start work on a corresponding pull request?

[lenormf]

What is the expected behaviour upon hitting ctrlc, and a shell process is stalled in the background, while in insert mode?

Quit insert mode and kill the process? One or the other? Surely some users would be unhappy about the side effect here, whichever one is picked.

Kakoune's differentiation of esc and ctrlc is predictable and consistent.

I reckon Vim developers never really envisioned users would eventually run shell commands from the editor, so they made ctrlc an equivalent for esc, because hitting ctrlc in insert mode feels natural when you use a shell all day already.

But Kakoune has first class support for shell integration, and placing job control and mode-escaping under the same umbrella would be a step backward.

[c-dinkel]

@lenormf your response gives the impression of somebody plugging their ears with their fingers shouting "LA LA LA" doing everything to preserve the status quo because "We're so special and different, but you're just a stubborn Luddite who hasn't thought things through, our way is best way, please now just realize that your pains are not real."

What is the expected behavior? It's literally explained in the first paragraph of @sanbor 's comment. Your answer would have felt much more meaningful if you had at least read the proposal first before dismissing it outright. "Surely some users would be unhappy [...], whichever one is picked." needs a citation. If Ctrl+C has always killed running shell commands and continues to always kill running shell commands, it just seems like a lazy excuse to not bother.

While Kakoune's differentiation is predictable and consistent, there is one big elephant in the room reason why key bindings in Kakoune generally work the way they do: because they work that way in vim. "Modal editing" in this and many other communities is very much a euphemism for "vim style editing".

If you reckon "Vim developers" never really envisioned users would eventually run shell commands from the editor, please just stop reckoning. Bram Moolenaar already had shell execution in his Vi IMitation starting with version 1.23 in 1993, just two years after the name change from Stevie to VIM. Release notes and discussion on comp.editors from 91 to 93 show as much, including the very deliberate nature of the choice to use escape sequences like <c-c> and <c-d> throughout the user interface.

"Placing job control and mode-escaping under the same umbrella [...]" smells like high grade bullshit. If you have technical difficulties making some key combination rebindable for the user because you can't handle the complexity you have bought with your dependencies or somesuch, then just say so. Don't portray this like some heroic choice in the best interest of the stupid user.

If this was truly just "modal editing", then all key combinations, including killing child processes, entering modes, and exiting modes, should be rebindable by the user. It is not though. It is vim style editing. And as such, it is poorly implemented.

EDIT: I wish to apologize for my tone, this comment was written and sent very hot, from a place of feeling disheartened by brusque dismissal of heartfelt pain, of feeling talked down to by an uninformed and uninterested party telling me I didn't do my homework. I shall leave the comment as is since I stand behind the substance, but hope you may take it lightly so it may not cause you as much suffering as yours caused me.

[lenormf]

I should have specified that making ctrlc have a non-deterministic side effect (namely, killing -or not- a shell process depending on some state) doesn't make for good user experience.

That's why I mentioned the corner case where a background shell process is running while in insert mode, even though it was mentioned in the thread already.

My other speculations are irrelevant, but I feel nonetheless that they stand (I'll admit your rambling was a bit unclear on why they don't).

At least you recognise that you have a problem, which is good, but please count to ten before hitting the reply button in the future. Otherwise, I might post a pun I just came up with that has to do with your current nickname and the way you communicate.

[c-dinkel]

I did indeed recognize that I have a problem. Sadly, that didn't make my problem go away.

Thank you for freely admitting that my rambling was unclear. I will graciously also admit that your other speculations were irrelevant.

I have not yet seen the light as to why ctrl+c should not be rebindable.

I shall now count to ten.

[mawww]

Hello,

Ctrl+C is not currently rebindable because it is processed special much earlier in the input stack (well before we know about modes and keymaps). This is the case because it needs to be processed immediately, including in cases were we usually defer input, in particular while evaluating a shell command.

In Kakoune, hooks can trigger shell commands, hence they can happen in almost any state, to keep things predictible we cannot start interleaving user input and shell processing (that often generate commands to run, so if the state gets modified by user input in the mean time things get unpredictible). Because of that, but also because shell command can do all kinds of shenanigans, Kakoune processes events while waiting for a shell command to finish (avoiding issues where the shell command fills up say a fifo buffer that Kakoune is supposed to read), but buffers most of those, except for a handful of events, such as window resizes and Ctrl+C keystrokes.

We might get blocked for various reasons inside that shell command and hence need a way to get out of it. Kakoune uses Ctrl+C because that matches the traditional keystroke to send a SIGINT to the current process group (which is exactly what Kakoune does). We also regularly launch shell processes in parallel with kakoune, such as when you type :make and being able to stop that compilation using Ctrl+C is also useful

I dont think this is quite the same as what Vim did back in 1993 because AFAIK it was not running in parallel with the shell command, it was running it in front of the vim process (that command even got access to the terminal), so Ctrl+C did not do anything out of those contexts, in Kakoune if

Providing support for remapping Ctrl+C is possible, but would add quite a bit of complexity for an arguably low value feature, so I do not consider the tradeoff worth it.

Hope that makes things a bit clearer.