Bracketed paste mode (2013) | Hacker News Reader

Bracketed paste mode (2013)

cirw.in

88 pointsolalonde29 comments

So that's what that is. I encounter that quite a bit when I try to paste and get annoyed trying to figure out how those extra characters got in there. I then would go and edit the start and stop of the line to remove them. I never actually tried just pressing enter for what looked like garbage at the start and end of the string.

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.

Terminal emulators typically only enable it in response to a request from an application. I’m not aware of one that enables paste bracketing by default.

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.

It could save a couple bytes for those on both ends to change the spec and enable it by default :)

It should do the opposite - find out when you run a program that doesn't support it and very strongly recommend you to use programs that support bracketed paste.

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

bash also has had this feature for something like six or seven years and it has been the default for almost two, so this isn't a reason to use or be specifically excited about zsh. (Of course, the ridiculously ancient copy of bash macOS ships as part of their protest against Free Software does not have this feature; we thereby need to be careful not to attribute anything to "now uses zsh/clang/etc." that was actually due to Apple holding us all back.)

> ridiculously ancient copy of bash macOS ships as part of their protest against Free Software does not have this feature

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.

Yeah, 10 years ago I used to love Richard Stallman and free-as-in-freedom and all that, but over the years it started to dawn on me that free software isn't really the solution to the worlds problems.... Plus, the GNU license does it in a really adversarial way. I actually have started to avoid GNU software in general, so I'm not forced to buy into this copyleft religion if I ever wanna look under the hood. I'll be the first to say Apple does some pretty messed up stuff but avoiding GNU is not one of those things. It's been 40 years. If Richard Stallman was right then we would be in a free software utopia right now.

I don't think you understand the spirit of the GNU license. The idea is to contribute your sources back to the community so that it can be built upon. Ultimately one individual can do only so much, but allowing the community to extend and improve upon derivatives allows us to stand upon each others' shoulders and build higher order software that is otherwise beyond the individual. There is nothing really adversarial about this idea.

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'd just like to interject for a moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux.

I discovered this when I upgraded bash shell to the latest version (5.0) with HomeBrew on my Mac machine. This in turn used the readline 8.0 library that had the bracketed paste feature enabled by default. I had to `set enable-bracketed-paste off` in my .inputrc to revert back to previous behavior.

I also get it all the time in windows terminal and got annoyed at having to manually removed the characters.

> safe-paste

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

Some terminal emulators[1] strip control characters (C0, C1 or both) out of clipboard or paste buffer contents when paste bracketing is enabled to avoid exactly this.

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!

> Update: Readline (as of v 7) and thus Bash (as of v4.4) now have support for bracketed paste mode too! You can enable it by adding set enable-bracketed-paste on to your ~/.inputrc.

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

wow, so after decades of using vim TIL finally how to solve one its most irritating warts, how not to have to manually set / turn off paste mode so that it won't auto-format pasted contents.

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...

Vim has supported it out of the box for six years (8.0.0210, https://github.com/vim/vim/commit/ec2da36ca48b40c0654b32a8d2...).

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

youch ... that is fascinating. And also depressing that when I look at the default version of vim on our servers it is 7.4 from 2015 (!)

iTerm2 has code to detect when the current host changes and then disables paste bracketing. An ssh session suddenly ending is a common cause of it being left on with annoying consequences.

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.

> An ssh session suddenly ending is a common cause of it being left on with annoying consequences. ... 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.

...then again, as the same problem could happen with any program crashing, one could argue it should be the shell's responsibility to reset terminal state after each program invocation. It could do so blindly (always send the disable codes) or set up ptys for children + pipe program output through itself and watch for state changes that need to be reset. I wonder if any shells do this, or if any common rc scripts set post-command execution wrappers to do so.

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)

How it all came to pass: https://invisible-island.net/xterm/xterm-paste64.html

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 ?

zsh is very nice like this

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

It is the same mechanism, and I agree that it is immensely useful.

With ipython and Deno pasting a giant amount of content is quite nice.

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 node that will run.

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

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

In python it will, if you paste it somewhere, remove the leading spaces that I added for HN, and copy and paste it again.

I feel like this is another entry in the "stop having invisible modes" category of software.

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).

I didn't know about bracketed paste until a few years ago.

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.

Thanks, I’ve occasionally come across this in foreign shells (my main shell doesn’t do it) and have long wondered what the cause is!

I'd upvote this only as an example of multi-column layout, very cool and under-utilized in this age of wide displays.

Reply on news.ycombinator.com