Dear Maintainer,

Configuring Ctrl-I as a keybinding is not working in the main <keymap>.

I tried in the console and with different terminal emulators (urxvt and
xterm) without success.

The Ctrl-I combination is working in other console apps like vim or
mutt.


Thanks!

Facundo Aguirre <legion82@gmail.com> writes:
the TAB character.  When ELinks receives this character from a
terminal, it cannot know whether you pressed the Ctrl-I key
combination or the Tab key.  ELinks then assumes you pressed the
Tab key, which is by default bound to frame-next.

Although ELinks lets you bind Ctrl-I to a command, that binding
will thus have no effect in VT100-like terminals.  You should
bind the Tab key instead.  There are similar problems with Ctrl+M
(which ELinks treats as Enter), and with Ctrl+H (which ELinks may
treat as Backspace, depending on termios settings).

It would be possible to change ELinks so that, if you try to bind
Ctrl-I to a command, it binds Tab instead.  However, I hesitate
to make such a change, because the same ELinks configuration file
can in principle be also used with other kinds of terminals.  In
particular, the Win32 console API does distinguish Ctrl-I from Tab.

Alternatively, ELinks could be changed to warn: "ELinks will not
find Ctrl-I key bindings on this terminal because it treats
Ctrl-I as the Tab key.  Do you want to bind Ctrl-I anyway?"  Or
something like that.  It might be tricky to implement for Ctrl-H,
because IIRC the master ELinks process does not know the termios
settings of its slaves.

Do those programs let you bind Ctrl-I and Tab to different
commands and use each one separately?

You are so right, I missed that Ctrl-I generates the same byte as the
TAB character. Vim and mutt don't treat Ctrl-I and Tab differently.
Now it's clear that is not an elinks problem.

Then it would be nice to be able to bind keys with octal numbers (or
like [27;5;9~).

Thanks!