From: Ihor Radchenko <email@example.com> To: Tim Cross <firstname.lastname@example.org> Cc: email@example.com Subject: Re: Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected) Date: Mon, 24 Jan 2022 22:16:33 +0800 [thread overview] Message-ID: <874k5tkym6.fsf@localhost> (raw) In-Reply-To: <firstname.lastname@example.org> Tim Cross <email@example.com> writes: > Ihor Radchenko <firstname.lastname@example.org> 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? > An alternative which might be worth considering would be to improve > documentation on using different popular terminal emulators, like tmux > which could cover both adapting org key bindings and adapting the key > bindings the emulator uses (a very quick google on this indicates you > can change the tmux bindings, but that detail is apparently not well > documented). Such documentation could include some guidelines on how to > identify the issue, identify at what layer (window manager, terminal > emulator, communication protocol etc) the problematic binding is being > intercepted etc. The interactions at this layer can be complex and > confusing, especially for users who don't have a clear model of how all > the layers interact. I am not aiming there for now. Just basic terminals. tmux, WMs, system-wide key bindings, etc are all higher level and can be configured by the user. We _might_ want to support the most popular shadowed bindings, but the problem with terminals is a lot more pressing. Users cannot really change what is supported. > A more long term strategy which I wonder if we should consider is > whether org would benefit from adopting the use of something like the > hydra package. Org needs a lot of key bindings - many more than most > other modes. Available bindings are in short supply. Perhaps leveraging > off something like hydras would both offer more flexibility and make it > easier to manage. Likewise, could transient mode help in this area? It may be a good idea. However, not all the users like hydra style. Note that we already have org-speed-commands. They provide somewhat similar functionality. We may extend them, allow using via transient keymap, or integrate org-speed-command-help with hydra/transient.el. Patches are welcome! Best, Ihor
next prev parent reply other threads:[~2022-01-24 14:19 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 [this message] 2022-01-25 8:51 ` Tim Cross 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style 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=874k5tkym6.fsf@localhost \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).