On Apr 27, 2014, at 10:44 AM, Daniel Colascione <dancol@dancol.org> 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.

I did figure this out a couple of hours after I discovered the weird behavior.

> 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 can save you some trouble - bracketed paste support works fine, the terminal sends the right control codes :-).

The problem is that I had this key-binding in some emacs-lisp code I wrote a while ago:

(global-set-key [(meta \])] 'something)
(global-set-key [(meta \[)] 'something-else)

After removing those global key bindings, it works great.

It might be worth putting some nicer error-reporting around those though, since M-] and M-[ are perfectly cromulent keys to want to bind (and I still bind them, I just have an (if (not (eq window-system nil))) around it now.

Thanks,

-g