Support for keymap editing

[taviso]

It's hard to press some keys in some terminals, I've noticed F10 doesn't work in gnome-terminal.

I really need to figure out the keymap file format and make a utility that can edit it.

I think this is a slightly over-engineered file format that has a serialized n-ary tree of key sequences.

For example, PgUp might generate \e[6~ and → might generate \e[C

It could be stored like this:

                \e
                /\
               [  Escape
              /\
             6  C
            /\   \
           ~  ?  Right
           |
          PgUp

This way you navigate the tree to figure out what the user just pressed.

[dtwilliamson]

Can you convert root/lotus/123.v10/sysV386/bin/keyedit from COFF to ELF?

file root/lotus/123.v10/sysV386/bin/keyedit
root/lotus/123.v10/sysV386/bin/keyedit: Intel 80386 COFF executable, no relocation info, no line number info, stripped, 4 sections, optional header size 28

As an aside, this seems to be a false match in file's magic:

file root/lotus/123.v10/keymaps/x/xterm
root/lotus/123.v10/keymaps/x/xterm: PDP-11 UNIX/RT ldp

[taviso]

I think it won't be easy to get that working because it's stripped unfortunately. I think I mostly figured out the format last night though - now I just have to translate my notes into C 😆

[sjuswede]

F1-F4 do not work in my rxvt-unicode-256color on Xubuntu 22.04. Works fine in XTerm though. F5 on work fine.

[taviso]

Understood. As soon as this is written I think adding support for more terminals will be easy, we can probably just automate it by grabbing the right key sequences from termcap.

[taviso]

Okay, I have a parser working, now just need to write an encoder!

$ ./a.out "^[[5;5~" < xterm
hdr.magic          0101
hdr.version        0001
hdr.zero           00000000
hdr.keytreesize    00001110
hdr.keydatasize    00000629
hdr.root           00000044
sequence '\E[5;5~' is Ctrl Pg Up, mapped to function 6158 {NEXT SHEET}
$ ./a.out "^[[21~" < xterm
hdr.magic          0101
hdr.version        0001
hdr.zero           00000000
hdr.keytreesize    00001110
hdr.keydatasize    00000629
hdr.root           00000044
sequence '\E[21~' is F10, mapped to function 6173 {GRAPH}

[taviso]

Okay, I have a first attempt.

I'm not really sure it's correct, and it's definitely not optimal, but it does seem to work okay.

There is a problem though, I didn't know this - but terminfo will only tell you the key sequences for application mode, and 123 runs in normal mode. I don't know if there a way to reliably translate them.

There are two solutions:

• Change 123 to run in application mode. This will break all the existing keymaps, but we can just regenerate them.
• Don't use terminfo. This would mean keymaps can only be generated interactively, like:

Please press the key you want for {HOME}
Please press the key you want for {END}
...

Alternatively, I could ask Thomas Dickey if there is a way to get the normal mode sequences, maybe there is and I just don't know it.

[taviso]

I think this patch is enough to switch to application mode. If anyone has any thoughts, please comment :)

diff --git a/graphics.c b/graphics.c
index df83279..673cf0e 100644
--- a/graphics.c
+++ b/graphics.c
@@ -272,6 +272,9 @@ int init_unix_display_code()
     // Initialize our ncurses, which we use for graphing.
     initscr();

+    // Switch to application mode so we can use terminfo.
+    keypad(stdscr, true);
+
     // We can draw graphs in color if available.
     start_color();
     use_default_colors();

[taviso]

Okay, I think I'm going to do it - better to break things now before the first release.

I'm about to push a change that generates keymaps in the Makefile instead of using hardcoded ones. I tried a few terminals but would really appreciate some testing and bug reports. I'm sure I broke a few keys somewhere 😆