emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected)
Date: Tue, 25 Jan 2022 19:51:15 +1100	[thread overview]
Message-ID: <87ee4wdufr.fsf@gmail.com> (raw)
In-Reply-To: <874k5tkym6.fsf@localhost>

Ihor Radchenko <yantar92@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>> Ihor Radchenko <yantar92@gmail.com> writes:
>>> Also, it appears to me that we may keep losing terminal-incompatible
>>> keys in future unless we provide some mechanisms to check terminal
>>> compatibility automatically. Any ideas?
>> No ideas on this. Problem being I don't think there is anything like a
>> terminfo service which will tell you about what capabilities/bindings a
>> terminal emulator has.
>> Just some thoughts on this -
>> I fear any such attempt is likely to end up in a game of 'wack-a-mole'.
>> While it makes some sense to provide alternative key bindings for Emacs
>> running under the GNU Linux console, especially given the limitations
>> under the console are well defined and constant, I'm not sure
>> we can provide reliable solutions or tests for different terminal
>> emulators (which will often 'reserve' various key bindings for their own
>> use. This is especially true for more advanced terminal emulators like
>> tmux.
> We cannot even handle GNU Linux console now. Technically, man 5 terminfo
> describes all the details on how to obtain terminal specs, but I am not
> sure how to extract useful information for key binding purposes. Can we
> do it programatically?

I probably wasn't clear enough in what I was trying to explain/suggest.
I'll try to clarify.

I think there are two different issues at play here. Key binding
limitations in the Linux console and key handling in different terminal
emulators. The first is fundamentally a limitation in the low level
kernel terminal driver and not much which can be done except choose
alternative key bindings when running under the linux console. The
second is more about limitations within the specific terminal emulator
program. Some emulators handle this better than others and it will be
near impossible to find key bindings which will work across all
different terminal emulators unless we restrict which key bindings we
use to a much smaller subset, which will inevitably mean many difficult
to use or less convenient bindings. This will just make everyone,
including those using more capable terminal emulators, suffer less
convenient key bindings and key bindings which are significantly
different from those used when running native window/GUI version. It
would make switching between GUI versions and terminal versions of Emacs
even less convenient. 

As an example, on my Ubuntu 21.10 system, when running Emacs under the
Linux console, C-c C-, completely fails. In fact,if you try to do
describe key for that combination, it won't work because Emacs never
sees the second key press. On the other hand, if I run Emacs inside
mate-terminal, Emacs will see C-c , and not C-c C-, (but it does get
both key presses). If I run Emacs under xterm, lxterm or uxterm,
everything actually works just fine. Describe key will report the
correct binding for C-c C-,

I don't believe terminfo will be of any help here. If you look at the
TERM setting for mate-terminal, uxterm, lxterm and xterm, they will all
reference various versions of xterm (often xterm-color or xterm-256color
etc). Looking at the terminfo definitions, I cannot see anything with
would indicate whether C-, for example is supported or not. I know of no
convenient and consistent way to determine if the terminal emulator
being used will support things like C-, or not. For the Linux console, I
think we can use the TERM environment variable to know when we are
running under the Linux console if we want to provide different key
bindings for some commands under the Linux console. There is also the
possibility you could create a keymap for the Linux console which would
configure some of the 'missing' modifier combinations to issue escape
sequences which can be used to emulate the modifier behaviour under GUI
environment - for example, I think you can create a keymap which will
allow C-up/C-dwon/C-left/C-right etc.

The question is, how useful will alternative key bindings actually be
for the Linux console. I imagine the user base for people who only work
under the Linux console is pretty small. For occasional use, the
alternative bindings are unlikely to be that useful as it is too hard to
change finger memory for occasional use and you probably won't remember
the different bindings anyway (I would probably just use M-x command in
these situations).

For the terminal emulator situation, I believe we should do nothing
except provide documentation on how to find or identify an appropriate
terminal emulator which will support the key bindings used by orc, such
as C-c C-,.

  reply	other threads:[~2022-01-25  9:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-19 12:08 Second Ctl in keychord not detected Loris Bennett
2022-01-19 12:48 ` Ihor Radchenko
2022-01-19 13:42   ` Loris Bennett
2022-01-19 14:20     ` Ihor Radchenko
2022-01-19 14:49       ` Loris Bennett
2022-01-20  2:11         ` Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected) Ihor Radchenko
2022-01-21  5:26           ` Tim Cross
2022-01-24 14:16             ` Ihor Radchenko
2022-01-25  8:51               ` Tim Cross [this message]
2022-01-21  8:03           ` Extend the existing alternative set of key bindings for terminals Loris Bennett
2022-01-23  6:58             ` Ihor Radchenko
2022-01-19 13:51 ` Second Ctl in keychord not detected Anssi Saari
2022-01-19 14:04 ` tomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ee4wdufr.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).