Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ctrl-C handling #78

Open
benwr opened this issue Jan 10, 2021 · 4 comments
Open

Ctrl-C handling #78

benwr opened this issue Jan 10, 2021 · 4 comments

Comments

@benwr
Copy link

benwr commented Jan 10, 2021

In other shells (fish, bash, zsh), pressing ctrl-c partway through entering a command aborts the current expression and puts the user at a new prompt. Rash prints (struct:exn:break user break #<continuation-mark-set> #<escape-continuation>) and seems to leave you in a strange state.

I mostly love rash so far; this is the only hiccup, since I use this behavior a lot in other shells.

@willghatch
Copy link
Owner

willghatch commented Jan 11, 2021 via email

@singpolyma
Copy link

Is readline eating ^C before rash can bind it, then? It's very nice that rash uses readline so all my custom inputrc keys "just work" but this papercut bites me as well.

@willghatch
Copy link
Owner

The thing is that in terminals, C-c is weird. Unlike most key events where the process just gets characters written to its input, C-c is handled specially by the terminal. Instead of sending a byte through the file descriptor to the controlling process, the terminal basically sends a signal to the kernel, which then sends SIGINT to the process. (This is a bit hand-wavey, as I would have to check some reference material to remember the exact details.) Programs that do something other than exit when C-c is pressed do so by registering a handler for C-c that does something sensible.

Anyway, Racket's handling of C-c is essentially to raise an exn:break exception, and there's not currently a good way to change that.

My plan for how to deal with this situation in a Racket-native editor is to either just catch that exception in the editing loop and translate it into a key event to do whatever is bound to C-c or actually change the process signal handler to do something similar. In principle this could be done with a readline FFI layer, but the current wrapper library is pretty simplistic, and doesn't actually expose much of the actual readline interface. In particular, it provides no way to programmatically edit the buffer. This could be fixed with a better readline FFI library, perhaps with much less effort than writing a Racket-native line editor, but ultimately my planned racket-native editor will be much more powerful than readline in various ways that I care about (IE be much more fully like Emacs -- pervasively programmable).

@singpolyma
Copy link

So, I have found that readline actually contains defaults to do what we want (https://tiswww.cwru.edu/php/chet/readline/readline.html#SEC44) but apparently the racket wrapper somehow overrides this and breaks even racket's own repl (racket/racket#2432)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants