I've seen it as a frustrating annoyance. Now that I know what it is, maybe I'll try hitting enter next time.

I think though, if a terminal (like iterm and windows terminal preview) was just going to enable this by default, they should have included some dialog the first time or two it happened. Something to explain what was going on.

If some shell or other line editor turns it on and doesn’t actually support the bracketing sequences, or fails to turn it off when leaving an interactive editing context, it might be worth filing that as a bug on that shell or line editor.

The mac now defaults to zsh which it seems to default to supporting it.

Well, bash changed their license from GPLv2 to GPLv3. So it is reasonable anyone who was using the old version would reconsider.

> that was actually due to Apple holding us all back

I know Apple does this and that their policy also unreasonably extends to GPLv2, but the GPLv3 really is difficult even for people who only want to write open source code unless they buy into everything GNU.

You should also understand that utopia is an imaginary construct of perfection, and by that definition there will never be a utopia for anything, ever. It's in fact the detractors of the free software movement who claimed that it was utopian, in the sense that it can never be achieved. The fact that GPL is the most widely used license for open source software today means it has easily quelled those claims.

I also don't know whether you realize that linux is GPL licensed. If you're set out to avoid linux in this day and age, especially as a programmer, that's quite something indeed.

I wonder how safe it actually is. Is it possible to escape from the brackets if the clipboard itself contains terminal control characters?

I believe[2] that xterm is not among them, which presents an argument that those other terminal emulators are not xterm-compatible :)

[1] Windows Terminal does for sure

[2] citation needed; I tested it a couple years ago and this is practically an anecdote!

And as of Readline 8.1 it is enabled by default. That broke the Python REPL on at least Arch Linux, Fedora, and on Mac with Homebrew, and assorted other things that didn't know about bracketed paste mode and so didn't turn it off [1].

[1] https://bugs.python.org/issue42819

given that it's something like 10 lines of code [0] it seems awfully silly that vim doesn't offer this built in.

[0] https://github.com/ConradIrwin/vim-bracketed-paste/blob/mast...

See the xterm-bracketed-paste help for more info.

After sending a bracketed paste, iTerm2 watches for half a second for `00~` to be echoed back and then offers to turn paste bracketing off for you.

Every modal reporting feature has similar problems: mouse reporting and focus reporting, in particular.

I've hit that with mouse reporting. Now that you mention it, seems like one way to address this would be the ssh client sending the ANSI escape sequences to turn off these features on exit. I wonder if the openssh developers would be open to doing so. It also seems possible to wrap ssh in a tiny shell/whatever script that calls ssh, saves the exit status, prints these disable codes, and returns the original exit status.

Bracketed paste mode (2013) - https://news.ycombinator.com/item?id=18329305 - Oct 2018 (22 comments)

Bracketed paste mode - https://news.ycombinator.com/item?id=6359316 - Sept 2013 (1 comment)

It mentions one of my pet peeves with bracketed paste:

(Although most terminal emulators are designed to emulate xterm) ... there are no terminfo/termcap capabilities for the feature. Vim's variables assume that a termcap description might provide different values (omitting the “t_” prefix), but other editors simply use hard-coded strings

For example, the readline library just checks whether $TERM == 'dumb' and outputs the control codes if not (provided enable-bracketed-paste is set, of course) . Can anyone help me understand why there is no terminfo entry like setbp=\E[?2004h and unsetbp=\E[?2004l ?

With bash when I pasted something with line breaks it would execute it right away

With zsh pasted contents is highlighted and you have to press enter to run it, even if there are line breaks in the pasted text

Not sure if that’s the same mechanism at play as described in the OP. But I love this about zsh

Deno:

press "`", press Ctrl-V or Command-V, press "`"

Now that is in _

With ipython:

press "'''", press Ctrl-V or Command-V, press "'''"

Now that is in _

In Deno this won't run something on Ctrl-V, until you press enter, which shows it supports bracketed paste:

  `test
  here`; throw new Error('ran this code without pressing enter');
  `end`

In ipython this won't run w/o pressing enter:

  '''line
  another
  '''
  raise RuntimeError('ran this w/o pressing enter')
  '''continued'''

No matter what the context, every OS, application and platform has some obscure feature which can be activated by the right random key combination, and provides no visual feedback or GUI controls to de-activate (so you get to just mash the keyboard till it hopefully turns off).

When I needed something similar in clickhouse-client, I implemented it as a heuristic - if the text is entered too quickly, it should be treated as pasted and there is no need to run a command after each crlf.

Then we've added the support for bracketed paste as well. But sometimes, it gives unpleasant artifacts.