[debbugs-tracker] bug#13839: closed (xterm/mintty control sequences support when formatOtherKeys = 1)

[GNU bug Tracking System]

Your message dated Tue, 08 Jul 2014 14:54:18 -0400
with message-id <address@hidden>
and subject line Re: bug#13839: xterm/mintty control sequences support when 
formatOtherKeys = 1
has caused the debbugs.gnu.org bug report #13839,
regarding xterm/mintty control sequences support when formatOtherKeys = 1
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
13839: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13839
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> xterm/mintty control sequences support when formatOtherKeys = 1
>
>
>
>
> Date: 
>
> Thu, 28 Feb 2013 10:42:47 -0500
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
>
>
>
>
> Moving this to the bug tracker.
>
> > --- Begin Message ---
> >
> >
> >
> > Subject: 
> >
> > Re: xterm/mintty control sequences support when formatOtherKeys = 1
> >
> >
> >
> >
> > Date: 
> >
> > Thu, 28 Feb 2013 22:33:58 +0800
> >
> >
> >
> >
> > User-agent: 
> >
> > Emacs+gnus
> >
> >
> >
> >
> > >>>>> "" == Stefan Monnier <address@hidden> 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 <address@hidden>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
> >     >>> 
> >
> > --- End Message ---
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#13839: xterm/mintty control sequences support when formatOtherKeys = 1
>
>
>
>
> Date: 
>
> Tue, 08 Jul 2014 14:54:18 -0400
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
>
>
>
>
> >> > 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
>
>
> --- End Message ---