frotz
frotz copied to clipboard
readline support
Would readline support be possible? Or running frotz with rlwrap perhaps.
What benefits would that provide that aren't already present?
Right now a subset of readline is supported. There are ctrl-a, ctrl-e, ctrl-f, ctrl-b, ctrl-k, ctrl-p, ctrl-n, AFAIK.
The ones I miss the most from readline are ctrl-w, alt-b, alt-f, alt-d, ctrl-y.
Searching of command history (ctrl-s) could be really nice aswell.
Since we spend hours editing that input line while we play, I think there would be great benefit in making it really convenient.
I understand making readline work on all platforms might be tricky, so it could be optional. Or at least, the ability to start frotz wrapped in 'rlwrap' would be a great solution aswell (rlwrap wraps applications such as telnet which don't have readline support enabling readline input). Right now rlwrap doesn't work with frotz, would that be hard to fix?
For context, pasting the essential readline key bindings taken from https://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC3
C-b
Move back one character.
C-f
Move forward one character.
DEL or Backspace
Delete the character to the left of the cursor.
C-d
Delete the character underneath the cursor.
Printing characters
Insert the character into the line at the cursor.
C-_ or C-x C-u
Undo the last editing command. You can undo all the way back to an empty line.
C-a
Move to the start of the line.
C-e
Move to the end of the line.
M-f
Move forward a word, where a word is composed of letters and digits.
M-b
Move backward a word.
C-l
Clear the screen, reprinting the current line at the top.
C-k
Kill the text from the current cursor position to the end of the line.
M-d
Kill from the cursor to the end of the current word, or, if between words, to the end of the next word. Word boundaries are the same as those used by M-f.
M-DEL
Kill from the cursor the start of the current word, or, if between words, to the start of the previous word. Word boundaries are the same as those used by M-b.
C-w
Kill from the cursor to the previous whitespace. This is different than M-DEL because the word boundaries differ.
C-y
Yank the most recently killed text back into the buffer at the cursor.
M-y
Rotate the kill-ring, and yank the new top. You can only do this if the prior command is C-y or M-y.
I suppose I could do that. But I'd rather not add a dependency on another library. One of the overall goals of Unix Frotz is to make sure it will run on old and obscure flavors of Unix. To achieve that, I try to keep external dependencies to a minimum. My attention for Frotz is focused right now on full Blorb audio support. Feel free to implement these keybindings and submit pull requests.
Yes I understand wanting to avoid dependencies. Do you have any suggestion why it doesn't work to launch frotz wrapped in rlwrap?
I thing rlwrap has problems because there's a lot of screen-handling going on. It might work with Dumb Frotz.
One thing that has mildly bugged me is that C-c will cause Frotz to quit. I can change this to abort the currently typed command like it works in Bash.
Okay, let's see C-c and C-k.
C-k was already in there.
C-c is trickier, since it is a signal (SIGINT). Easiest thing to start with is to make C-c a NOOP. That way, a player accientally hitting C-c won't lose progress, at least.
an alias for Ctrl-C that empties the line
IMO, if system line editing can't be used (lots of reasons for that) then that is what should be (partially) emulated. I.e. the POSIX control codes used by stty
. Either use the defaults or (better) look up the terminal control codes set for the current terminal.
The defaults are that Ctrl+U is line erase/reset and that Ctrl+C is interrupt. I think it would be a mistake to make Ctrl+C do anything else by default.
FYI, the full set from stty all
on my system:
eof ^D
eol <undef>
eol2 <undef>
erase ^?
erase2 ^H
werase ^W
intr ^C
kill ^U
quit ^\
susp ^Z
start ^Q
stop ^S
dsusp ^Y
lnext ^V
reprint ^R
status ^T
discard ^O
Would it be an acceptable compromize to let ctrl-c terminate the application, but first ask the user for confirmation. That is, the same behaviour as typing "quit".
During cleanup for 2.45, I need to reevaluate which readline options I want to support and what, if any of this should be put into the other interfaces.
At first it seems that curses and readline don't mix, but perhaps they do.