GNU bug report logs - #13839
xterm/mintty control sequences support when formatOtherKeys = 1

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#13839: closed (Re: bug#13839: xterm/mintty control sequences
 support when formatOtherKeys = 1)
Date: Tue, 08 Jul 2014 18:55:04 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#13839: xterm/mintty control sequences support when formatOtherKeys = 1

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 13839 <at> debbugs.gnu.org.

-- 
13839: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ren Victor <victorhge <at> gmail.com>
Cc: 13839-done <at> debbugs.gnu.org
Subject: Re: bug#13839: xterm/mintty control sequences support when
 formatOtherKeys = 1
Date: Tue, 08 Jul 2014 14:54:18 -0400

>> > The default value is 41 (in xterm latest version manual).
>> 
>> It seems that indeed the regexp could need revision, but I'd first like
>> to understand what's going on.  The test we want to make is "make sure
>> this terminal understands this and that feature".  So the "P v" field
>> (the version number) only makes sense if the terminal is actually an
>> xterm (or uses a version numbering that implies the same featureset).
>> In my xterms the "P p" value is always 0 and not 41 as you seem to suggest.

In the mean time, we've indeed changed this regexp to accept other
numbers as well, and sure enough this bumped into new bugs with
non-xterm terminals, and we've hacked our way around those as well.
So I think this can be closed now.  Thank you,


        Stefan

[Message part 3 (message/rfc822, inline)]

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: xterm/mintty control sequences support when formatOtherKeys = 1
Date: Thu, 28 Feb 2013 10:42:47 -0500

[Message part 4 (text/plain, inline)]

Moving this to the bug tracker.

[Message part 5 (message/rfc822, inline)]

From: Victor Ren <victorhge <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, emacs-devel <at> gnu.org
Cc: Ren Victor <victorhge <at> gmail.com>
Subject: Re: xterm/mintty control sequences support when formatOtherKeys = 1
Date: Thu, 28 Feb 2013 22:33:58 +0800

>>>>> "" == 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
    >>> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.