Second Ctl in keychord not detected

Second Ctl in keychord not detected

[Loris Bennett]

Hi,

This is not really an Org question but an Emacs or possibly tmux
problem.  However, the problem manifests itself in an Org context.

I have started using Org on a remote server which has Emacs 27 (Org 9.3)
installed.  I am using tmux and want to run

  org-insert-structure-template

which is bound to

  C-c C-, 

When I type that, however, the function

  org-priority

is executed instead, which is bound to 

  C-c ,

Does anyone know what is happening to the second Ctl and how the problem
can be fixed?

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Second Ctl in keychord not detected

[Ihor Radchenko]

"Loris Bennett" <loris.bennett@fu-berlin.de> writes:

>   C-c ,
>
> Does anyone know what is happening to the second Ctl and how the problem
> can be fixed?

Try to run M-x describe-key <RET> C-c C-, and look at the output.

Best,
Ihor

Re: Second Ctl in keychord not detected

[Loris Bennett]

Hi Ihor,

Ihor Radchenko <yantar92@gmail.com> writes:

> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>>   C-c ,
>>
>> Does anyone know what is happening to the second Ctl and how the problem
>> can be fixed?
>
> Try to run M-x describe-key <RET> C-c C-, and look at the output.

The second C- disappears.

I also get

  C-c C-.  ->  C-c .
  C-c C-;  ->  C-c ;
  C-c C-:  ->  C-c :
  C-c C-\  ->  C-c \
  C-c C-=  ->  C-c =

but

  C-c C-c  ->  C-c C-c
  C-c C-_  ->  C-c C-_
  C-c C-@  ->  C-c C-@

Gnome could potentially also be intercepting some keys.

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Second Ctl in keychord not detected

[Anssi Saari]

"Loris Bennett" <loris.bennett@fu-berlin.de> writes:

> installed.  I am using tmux and want to run
>
>   org-insert-structure-template
>
> which is bound to
>
>   C-c C-, 
>
> When I type that, however, the function
>
>   org-priority
>
> is executed instead, which is bound to 
>
>   C-c ,

> Does anyone know what is happening to the second Ctl and how the problem
> can be fixed?

Yes. I actually asked about this recently. The problem is that in a
terminal, C-, doesn't exist. Hitting C-, gets you just a comma. In other
words, there is no control character in existence that would be sent in
a terminal when the user hits C-,.

I asked for suggestions for remapping org-insert-structure-template to
some other keys and got a suggestion on how to find what key
combinations are free. Also a suggestion to use older way to get the
template (require 'org-tempo and use < s TAB).

Problem with that old way is that it doesn't wrap region in the
+BEGIN_SRC/+END_SRC tags, it just dumbly inserts them. I typically start
writing code in an ORG document and *then* realize it should be inside
those tags so C-c C-, would be perfect. Just not in a terminal.

It might be worth reporting this key binding as a bug since it doesn't
work in a terminal.

Other than mapping org-insert-structure-template to some other key
combination or using <sTAB, if your terminal allows it, map C-, in
terminal-specific configuration to send something with C-, and then
configure emacs to match. Painful if you use different terminals and I
know at least one which uses C-, as a shortcut for settings.

Come to think of it, maybe you could remap keys in tmux if you always
use tmux, then it doesn't matter which terminal you use.

Re: Second Ctl in keychord not detected

[tomas]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Wed, Jan 19, 2022 at 01:08:10PM +0100, Loris Bennett wrote:
> Hi,
> 
> This is not really an Org question but an Emacs or possibly tmux
> problem.  However, the problem manifests itself in an Org context.

I guess this is tmux. It behaves more or less like an oldskool terminal,
where C-<key> is transferred as the ASCII code with bit 7 masked out.
This would mean only C-@ (mapped to ASCII 0, which might have its own...
interesting issues) through a few chars after CTRL-Z do make sense in
this context.

This "protocol" can't even express things like CTRL-. or CTRL-, -- that
luxury is reserved to more GUI-ish environments :-)

(NOTE: just a guess, I haven't direct experience with tmux).

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Second Ctl in keychord not detected

[Ihor Radchenko]

"Loris Bennett" <loris.bennett@fu-berlin.de> writes:

>>> Does anyone know what is happening to the second Ctl and how the problem
>>> can be fixed?
>>
>> Try to run M-x describe-key <RET> C-c C-, and look at the output.
>
> The second C- disappears.
>
> I also get
>
>   C-c C-.  ->  C-c .

Then, it is terminal input problem. See
https://stackoverflow.com/questions/11110801/why-does-ctrl-not-work-when-i-bind-it-to-a-command-in-emacs/11118511#11118511

Best,
Ihor

Re: Second Ctl in keychord not detected

[Loris Bennett]

Ihor Radchenko <yantar92@gmail.com> writes:

> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>>>> Does anyone know what is happening to the second Ctl and how the problem
>>>> can be fixed?
>>>
>>> Try to run M-x describe-key <RET> C-c C-, and look at the output.
>>
>> The second C- disappears.
>>
>> I also get
>>
>>   C-c C-.  ->  C-c .
>
> Then, it is terminal input problem. See
> https://stackoverflow.com/questions/11110801/why-does-ctrl-not-work-when-i-bind-it-to-a-command-in-emacs/11118511#11118511

You're right, the problem also happens locally when I start Emacs with
'-nw'.  Thanks for the link - I'll have a look at the various solutions,
although it might just be easier to rebind the command ;-)

Cheers,

Loris

-- 
This signature is currently under construction.

Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected)

[Ihor Radchenko]

"Loris Bennett" <loris.bennett@fu-berlin.de> writes:

>> Then, it is terminal input problem. See
>> https://stackoverflow.com/questions/11110801/why-does-ctrl-not-work-when-i-bind-it-to-a-command-in-emacs/11118511#11118511
>
> You're right, the problem also happens locally when I start Emacs with
> '-nw'.  Thanks for the link - I'll have a look at the various solutions,
> although it might just be easier to rebind the command ;-)

On Org side, we have an alternative set of key bindings that is more
compatible with terminals (see org-use-extra-keys). I think that C-c C-,
should also be covered there. Or maybe some other keys as well.

Loris, would you be interested to check which default bindings from
org-mode-map work and which don't work in tmux/terminal and report here?

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?

Best,
Ihor

Re: Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected)

[Tim Cross]

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.

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?

Re: Extend the existing alternative set of key bindings for terminals

[Loris Bennett]

Hi Ihor,

Ihor Radchenko <yantar92@gmail.com> writes:

> "Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>
>>> Then, it is terminal input problem. See
>>> https://stackoverflow.com/questions/11110801/why-does-ctrl-not-work-when-i-bind-it-to-a-command-in-emacs/11118511#11118511
>>
>> You're right, the problem also happens locally when I start Emacs with
>> '-nw'.  Thanks for the link - I'll have a look at the various solutions,
>> although it might just be easier to rebind the command ;-)
>
> On Org side, we have an alternative set of key bindings that is more
> compatible with terminals (see org-use-extra-keys). I think that C-c C-,
> should also be covered there. Or maybe some other keys as well.
>
> Loris, would you be interested to check which default bindings from
> org-mode-map work and which don't work in tmux/terminal and report here?

In principle, yes, but the mode map is quite extensive.  Is there any
way of doing that systematically?  Or is the idea that I just keep a
record of all the issues that I stumble across?

Cheers,

Loris

> 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?
>
> Best,
> Ihor
-- 
This signature is currently under construction.

Re: Extend the existing alternative set of key bindings for terminals

[Ihor Radchenko]

"Loris Bennett" <loris.bennett@fu-berlin.de> writes:

> In principle, yes, but the mode map is quite extensive.  Is there any
> way of doing that systematically?  Or is the idea that I just keep a
> record of all the issues that I stumble across?

I do not know a good way to do it systematically, other than looking
into the contents of org-mode-map and trying things.

The idea is to keep record of the problematic bindings and later discuss
possible alternatives that will be automatically enabled when you load
Emacs in terminal.

The current alternatives are the following:

  - "C-c C-x c ->            org-table-copy-down
  - "C-c C-x m ->            org-meta-return
  - "C-c C-x M ->            org-insert-todo-heading
  - "C-c C-x RET ->          org-meta-return
  - "ESC RET ->              org-meta-return
  - "ESC <left> ->           org-metaleft
  - "C-c C-x l ->            org-metaleft
  - "ESC <right> ->          org-metaright
  - "C-c C-x r ->            org-metaright
  - "C-c C-x u ->            org-metaup
  - "C-c C-x d ->            org-metadown
  - "C-c C-x L ->            org-shiftmetaleft
  - "C-c C-x R ->            org-shiftmetaright
  - "C-c C-x U ->            org-shiftmetaup
  - "C-c C-x D ->            org-shiftmetadown
  - "C-c <up> ->             org-shiftup
  - "C-c <down> ->           org-shiftdown
  - "C-c <left> ->           org-shiftleft
  - "C-c <right> ->          org-shiftright
  - "C-c C-x <right> ->      org-shiftcontrolright
  - "C-c C-x <left> ->       org-shiftcontrolleft

Best,
Ihor

Re: Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected)

[Ihor Radchenko]

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?

> 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

Re: Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected)

[Tim Cross]

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-,.