Feature request: Ctrl-C should not end top-level session

[stevemolloy]

At present, ctrl-c ends the session in almost the same way that ctrl-d does. The difference is that ctrl-c will end the session even if there is a partially entered command typed in -- in this case ctrl-d does nothing.

I propose that this should be changed to mirror the behaviour seen in other cli's. For example bash and the python repl.

In these situations, ctrl-c sends a keyboard interrupt, but does not drop out of the repl. If a partial command is typed in, ctrl-c will ignore it and present you with a blank line. And most importantly, it will not drop you out of the repl. Due to this, I have a couple of decades of muscle memory that makes me hit ctrl-c when I badly mistype a command, and want to start over on a blank line. In the scryer top-level, this muscle memory causes me to kill the session more often than I would like to admit :D

[hurufu]

I think right now you can use all your standard terminal shortcuts:

^w - clear last word ^u - clear line ^d - close input

And others, they all seem to work at least for me.

Regarding your point: For me intuitive behavior for SIGINT (^c) would be stop whatever it is doing and drop to the top level, for SIGQUIT (^\) would be to terminate process unconditionally.

[stevemolloy]

Agreed. I would like ctrl-c to stop everything and drop to the top-level. But at the moment it quits the top-level and drops me back at the bash prompt.

[UWN]

What OS? Under Linux C-c aborts as (it seems) you expect it.

?- repeat,false.
^C   error('$interrupt_thrown',repl/0).

[stevemolloy]

Yes, that behaviour is what I would have expected.

What goes against my expectations is if you start writing a command, but do not execute it, and then ctrl-c -- this will dump you out of the top-level and back to the bash prompt.

?- empty_assoc(A0), phrase(ast(Ast
[smolloy@archdell machine_protect]$

This (to me) is counter intuitive.

[hurufu]

For now you can just press ctrl-u to clear the line – it is much better to memorize this shortcut because it is more universal then ctrl-c.

[triska]

Also common Emacs keybindings work well: C-a to go to the start of the line, C-k to remove the remainder of the line, M-b to go back a word, M-f to go forward etc.

[stevemolloy]

For now you can just press ctrl-u to clear the line – it is much better to memorize this shortcut because it is more universal then ctrl-c.

Thanks for the tip. I have a few hard-wired into my hands (ctrl-w to delete words, etc.), but ctrl-u to clear the line is a new one.

I would still argue that having the Rust level catch the ctrl-c and then exiting the top-level is not expected behaviour. It should (I think) be caught by the prolog system. But it's not a critical issue.

[UWN]

Just realizing: C-/ is undo (handy on US keyboards), probably the same as C-u.

[hurufu]

Also ctrl-c is very special, because it maps Unix signal to Prolog exception, for example you can't escape from this program, by pressing ctrl-c:

X = catch((repeat,false), _, X), call(X).

only ctrl-\ works – because it just causes Scryer to dump memory and exit.

So, I would think that a consistent solution would be to show error($interrupt_thrown,get_single_char/1) and go back to the top-level prompt. Similar to what is done in Python for example.

Maybe registering custom signal handlers would be neat, but it can be tricky to implement right, because of how signals work.

[UWN]

Catching any exception is a receipt for disaster, since this may mask out unexpected problems. Also note that in your case, you will only catch all exceptions that are the same (there is only one variable _).

[hurufu]

[...] you will only catch all exceptions that are the same (there is only one variable _).

I didn't know that, thanks. It makes handling exceptions more difficult.