Tim Cross <theophil...@gmail.com> writes: > Ihor Radchenko <yanta...@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? > 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