On 04/27/2014 10:44 AM, Daniel Colascione wrote:
> On 04/27/2014 10:27 AM, Jan Djärv wrote:
>> 27 apr 2014 kl. 09:47 skrev Glyph <glyph@twistedmatrix.com>:
>>
>>>
>>> I'm using snapshot builds from http://emacsformacosx.com/.  Somewhere
>>> between the 4/13 snapshot and the 4/24 snapshot, "paste" in an OS X
>>> terminal (running with -nw) results in garbage characters on either side
>>> of the paste.
>>>
>>> For example, if I paste the URL, it looks like
>>> 200~http://emacsformacosx.com/201~, or causes jumping around within the
>>> buffer (for example, when filing this bug, it jumped to the beginning of
>>> the buffer and pasted the URL and the "201~" before the From:).
>>>
>>>
>>
>> I can't reproduce this.  Did you start emacs with -Q?
>> What application did you copy from?
>> What key combination did you use to paste?
> 
> That's the new bracketed paste system supoport. Emacs is correctly
> sending the terminal the sequence to enable bracketed paste mode, but
> isn't correctly the start sequence. I hope we don't have to make this
> feature conditional.
> 
> OP, what's in *Messages*? If you M-x trace-function-background
> xterm-paste, do you see messages in *trace-output*? What happens if you
> manually type ESC [ 2 0 0 ~ ?
> 

I have an idea, actually. What if Terminal.app, in its infinite glory,
is sending ESC twice, once because bracketed paste support is enabled,
and once because Command is held down? Does the following patch help or
change the behavior in any way?

=== modified file 'lisp/term/xterm.el'
--- lisp/term/xterm.el	2014-04-27 23:26:42 +0000
+++ lisp/term/xterm.el	2014-04-27 23:30:39 +0000
@@ -428,6 +428,8 @@
     ;; Recognize the start of a bracketed paste sequence.  The handler
     ;; internally recognizes the end.
     (define-key map "\e[200~" [xterm-paste])
+    ;; Work around Terminal.app bug?
+    (define-key map "\e\e[200~" [xterm-paste])

     map)
   "Function key map overrides for xterm.")