From: Tim Cross <firstname.lastname@example.org> To: email@example.com Subject: Re: Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected) Date: Fri, 21 Jan 2022 16:26:00 +1100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <871r13kvfg.fsf@localhost> Ihor Radchenko <email@example.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. 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. 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?
next prev parent reply other threads:[~2022-01-21 9:09 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 [this message] 2022-01-24 14:16 ` Ihor Radchenko 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).