GNU bug report logs - #17357
24.4.50; garbage characters when pasting in an OS X terminal

Previous Next

Full log

Message #23 received at 17357 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 17357 <at> debbugs.gnu.org, Glyph <glyph <at> twistedmatrix.com>
Subject: Re: bug#17357: 24.4.50;
 garbage characters when pasting in an OS X terminal
Date: Sun, 27 Apr 2014 23:55:22 -0400

>> (global-set-key [(meta \])] 'something)
>> (global-set-key [(meta \[)] 'something-else)
> Your numeric keypad bindings should have broken too.
> Also, we bind these keys in xterm-function-map. Shouldn't that map
> override global-map?

No.  The way input decoding takes place is very delicate and what "takes
priority" when is quite delicate.

Yes, a ?\M-\] binding in input-decode-map takes precedence over such
a binding in global-map.

But after reading ?\M-\] we don't have enough input (yet) to translate
that to something else, so Emacs has a choice to make:
- either wait for more input, in the hope that it will match one of the
  bindings under the ?\M-\] prefix in input-decode-map.
- or stop right here since we do have a valid binding already (in the
  global map).
And Emacs chooses option 2 because option 1 is too risky.
E.g. Option 1 would prevent ESC ESC ESC from working, since there's
pretty much always an ESC prefix in input-decode-map, so we'd always
"wait for more" after an ESC.

Maybe it would make sense to try and improve the input-decode-map
support with a way to say: if we've seen "ESC [", we have enough
evidence that there is a real escape sequence coming, so keep waiting
for input as long as it matches something in input-decode-map.


        Stefan

Previous Next

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