GNU bug report logs -
#13839
xterm/mintty control sequences support when formatOtherKeys = 1
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Moving this to the bug tracker.
[Message part 2 (message/rfc822, inline)]
>>>>> "" == Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>> For example, pressing C-0 in xterm will send control sequence
>> "\e[27;5;48~" by default, which is supported now. When
>> "formatOtherKeys" is set to 1, C-0 is sent as "\e[48;5u" which is
>> another shorter format.
>> The easiest change I can image is to define a lot of key binds
>> for those control sequence, for example, (define-key map
>> "\e[48;5u" [?\C-0])
> Y see, that looks fine. If you can prepare a patch for it, I'd
> be very happy to install it. Or can we simply take all the
> "\e[27;NN,MM~" and add a corresponding "\e[MM;NNu"? If so, I can
> write the patch myself.
Yes, I think so. Maybe this is the better way than checking terminal
capacities and then deciding to enable which format.
/Victor
> Stefan
>> On Wed, Feb 27, 2013 at 9:54 PM, Stefan Monnier <monnier <at> iro.umontreal.ca>wrote:
>>> > When setting "formatOtherKeys" resource to 1 in xterm, 'CSI u'
>>> format is > used for non-standard keycodes. This is also how
>>> mintty support > "modifyOtherKeys" by default.
>>>
>>> > But in term/xterm.el, only 'CSI 27" format is supported.
>>>
>>> > I think it is worth supporting "CSI u" format control
>>> sequences. > What do you think of adding them to
>>> teerm/xterm.el? or anyone can do it?
>>>
>>> I'm not familiar with those "CSI 27" and "CSI u" formats (the
>>> name vaguely reminds me of distant memories, but that's about
>>> it). Could give us an idea of what kind of changes to
>>> term/xterm.el that would entail?
>>>
>>>
>>> Stefan
>>>
This bug report was last modified 10 years and 323 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.