# bracketed-paste



## Spity (Jul 13, 2021)

I'm on FreeBSD 13, and I don't know how to disable "_bracketed_ _paste"_. I already tried with inputrc (set enable-bracketed-paste off) and it does not work. I switched to zsh and it is still there, active.


----------



## SirDice (Jul 13, 2021)

Spity said:


> I don't know how to disable "_bracketed_ _paste"_


It's a function of the terminal, not the shell. 

```
Copying and Pasting Text with a Mouse
     Copying and pasting text from the screen with a mouse is supported.
     Press and hold down mouse button 1, usually the left button, while moving
     the mouse to select text.  Selected text is highlighted with reversed
     foreground and background colors.  To select more text after releasing
     mouse button 1, press mouse button 3, usually the right button.  To paste
     text that has been selected, press mouse button 2, usually the middle
     button.  The text is entered as if it were typed at the keyboard.  The
     VT_TWOBUTTON_MOUSE kernel option can be used with mice that only have two
     buttons.  Setting this option makes the second mouse button into the
     paste button.  See moused(8) for more information.
```
See vt(4)


----------



## Spity (Jul 13, 2021)

But,  im on gnome. It's the same?


----------



## SirDice (Jul 13, 2021)

Spity said:


> But, im on gnome. It's the same?


Then it's the copy/paste functionality of Xorg.


----------



## grahamperrin@ (Jul 13, 2021)

*TIL* it's possible to paste in xterm.

It's taken me this long (years) to discover because I 'grew up' using mice without middle buttons. Ha.


----------



## mtu (Jul 13, 2021)

At least for shells/bash, the solution is to either `set enable-bracketed-paste off` in ~/.inputrc (like you tried), or compile devel/readline configured with `--disable-bracketed-paste-default`. There's a bug report that aims to make this the default: PR 253142

Check if your application (shell, terminal, could be several things involved) actually uses devel/readline, or if you need to look for that setting somewhere else.


----------



## memreflect (Jul 14, 2021)

You mentioned zsh, so I had a look at the man page zshall(1).  ZLE is the line editor that zsh uses rather than devel/readline or something similar.  It turns out that you can simply `unset zle_bracketed_paste` in an interactive session to disable it for that session.  You can also simply disable the highlighting to retain the "safety" feature provided by bracketed paste using `zle_highlight=('paste:none')` in your .zshrc.

Zsh has 8 possible files that it reads upon startup, and using `unset zle_bracketed_paste` in *every one of them* still did not disable bracketed paste at the start of an interactive session, whether it was a login shell or not.  Bracketed paste is enabled by default, so if it's unset (or not an array) then it is subsequently enabled.  This behavior makes some sense at least: startup files are read prior to ZLE's initialization because the session may not be interactive, and if ZLE's initialization code doesn't find an array named zle_bracketed_paste, probably because it was unset or simply not declared in a startup file, then it will create the array and set default values.

Rather than unsetting the variable in vain, you need to declare the variable as an empty array using `typeset -A zle_bracketed_paste` in something like .zshrc instead of unsetting it.  This only works because the ZLE code simply checks whether zle_bracketed_paste is an array of length 2 to determine whether to print the "bracket" strings.  This means if it's an array with any other length, the "bracket" strings will not be printed to the terminal, and the terminal will not interpret the pasted text.

Note that some terminals may still choose to "bracket" pasted text on their own, but this at least solves the problem with ZLE.


----------



## grahamperrin@ (Jul 14, 2021)

mtu said:


> PR 253142



Will that make it less easy for me to paste?


----------



## ralphbsz (Jul 14, 2021)

Let me ask a more fundamental question: Why do you want to disable bracketed paste? What's there to gain?

Cut and paste is good, we mostly agree, right?

One of the problems with cut and paste: A lot of programs that consume input today are designed around being helpful, with thing like auto-complete, indentation, immediate syntax colorization, and such. They are designed around the normal typing speed: A few dozen to hundreds of ms between keystrokes, and the human brain can react to visual cues relatively quickly between keystrokes. That's great, and many people like it (and some don't). But pretty universally, these features don't make sense (and don't work, or work badly) when pasting text. Classic example: When I'm typing in code, my editor automatically indents it correctly, and it is aware of syntax: when I hit return, the cursor is at a sensible column in the next line, not at the beginning of the line. And the editor is aware of the semantics of the code that I'm typing, so if for example I type "else", the next line is automatically indented less. But this breaks when the stuff being typed is not actually being typed by a human, but is being pasted. For for example at the end of the line it pastes a "return" (really a CR character), and the smart input knows to indent, but the paste then supplies all the necessary spaces already. When someone pastes source code, there is no need to run heuristics to determine the semantics, nor is there a need to adjust the indentation; on the contrary, pasted source code should be copied in literally.

And bracketed paste fixes exactly that problem: It allows the program that consumes the "keystrokes" to know that what it is seeing is not being typed by a human at a keyboard, but is already finished. For example, the editor can turn off auto-indent.

So why do you want to turn that off?


----------



## mtu (Jul 14, 2021)

grahamperrin said:


> Will that make it less easy for me to paste?


Arguably, it will make it easier. Bracketed paste requires an extra keystroke that's otherwise not necessary.


ralphbsz said:


> And bracketed paste fixes exactly that problem: It allows the program that consumes the "keystrokes" to know that what it is seeing is not being typed by a human at a keyboard, but is already finished. For example, the editor can turn off auto-indent.
> 
> So why do you want to turn that off?


When pasting commands into a terminal, it requires an extra keystroke before they are executed, provided that newline(s) exist after the command(s). To some, that's a useful security feature (especially for users who frequently paste commands from StackExchange or something).

To others—myself included—it's an unnecessary annoyance, and an irritating change to the way terminals have worked for decades. I'd say it's a POLA violation, too, as evidenced by the bug report and the forum threads linked therein.


----------



## _martin (Jul 14, 2021)

Oh, I'm with you mtu. The whole bracketed paste is one big annoyance. In gdb I'm use to paste and look at the (other) data at the same time. The highlighted text just steals my attention from other part of the screen. It's a muscle memory -- you look when something gets highlighted.
If I copy-paste larger command during the night the highlighted text is really sore to my eyes. And last, but not least, it's matter of a personal preference. I don't like pasted text to be highlighted. It was not before and I want to keep it that way.

The extra keystroke can be a feature but it should be possible to toggle on/off in the user settings. I use iTerm2 and I set it there.


----------



## mtu (Jul 14, 2021)

_martin said:


> The extra keystroke can be a feature but it should be possible to toggle on/off in the user settings. I use iTerm2 and I set it there.


Funny, it's the other way around for me  The optics don't bother me much, but the extra keystroke is terrible. It forces my right hand from the mouse back to the keyboard (when I'm not expecting it), which is a major annoyance.

Clearly, we're looking at a case of … 








						Workflow
					






					xkcd.com


----------



## _martin (Jul 14, 2021)

Hehe, I know that one. 

But here truly it's an annoying "feature".  Users are only asking for an option to turn it off. And computers are here to help with your job, not to annoy you. At least, that's the idea.


----------



## ralphbsz (Jul 14, 2021)

Interesting. I see two potential answers here: (a) Don't like bracketed paste because it changes the way cut-and-paste works, and (b) don't like it because one has to type return in the shell after a pasted command, even if the pasted text contained an end-of-line. I fully understand (b), that's a design choice that may be annoying to some, and that depends on taste.

So back to the original question, how to turn it off: Is it sufficient to turn it off in the terminal emulator? I know the one I use (iTerm2 on the Mac) has  the ability to turn it off, either for the current session, or permanenty.


----------



## mtu (Jul 14, 2021)

ralphbsz said:


> So back to the original question, how to turn it off: Is it sufficient to turn it off in the terminal emulator? I know the one I use (iTerm2 on the Mac) has  the ability to turn it off, either for the current session, or permanenty.set enable-bracketed-paste off


For all I know so far, you can compile devel/readline to have the option off by default, which should take care of all consumers of that library. Alternatively, you can `set enable-bracketed-paste off` in ~/.inputrc, which _should_ also take care of consumers—but who knows. I've personally tested it to work as expected for shells/bash.

But then there's memreflect 's findings regarding shells/zsh, which seems to be a right mess. Moreover, SirDice has indicated that terminal emulators might also be at play. So … yeah ¯\_(ツ)_/¯


----------



## ralphbsz (Jul 14, 2021)

Bracketed paste means: The terminal (emulator) sends a special control sequence before and after the pasted text. Terminals don't do that all the time; some program they are talking to can explicitly turn it off and on. So one way to get rid of it is to tell the terminal to not send the bracketed paste sequence, which means to ignore the command from the program to turn it on.

And the other side is: Terminal input goes into a program, and that program has to (a) turn bracketed paste on and off, and (b) do something different in response to pasted text (when it can be recognized due to the escape sequence). In reality, there are not very many programs that consume terminal input interactively: shells, editors (emacs, vim, nano, ...), interactive programming environments (such as the python interpreter or PHP), debuggers, and a few others. So another strategy is to teach all of those to do the right thing. Some programs use GNU readline for terminal input (in particular bash), but because of the GPL consequences, that's less common than one might assume, in particular in BSD.


----------



## PMc (Jul 14, 2021)

ralphbsz said:


> Let me ask a more fundamental question: Why do you want to disable bracketed paste? What's there to gain?
> 
> [...]
> So why do you want to turn that off?



Simple usecase: you have an xterm with history. You go back twenty pages in the history, and there is a dialogue, and you want to copy/paste that dialogue back into the xterm's currently running command, line by line (but without the prompt that is there).
Without the bracketed-thing you can simply do that: copy the whole line, until the right edge of the xterm, paste it in and it will create a linefeed. With the bracketed-thing it will stop, and you have to hit CR explicitely after each line. Which will scroll the xterm back down (if there is "Scroll to Bottom on Key Press", which did make sense up to now) and then one can page back up the twenty pages and search for the proper dialogue. Line by line.
Maybe there is a workflow that could do this properly with the bracketed-thing active. But I didn't find it, and I don't want to search for it, because all did already work fine until now, and there is no improvement now, just a "Verschlimmbesserung".


----------



## ralphbsz (Jul 14, 2021)

For me, that exact use case works excellently pasting into emacs and into bash. And for emacs, it works even better than it used to, because when pasting code, the auto-indent turns itself off for pasted code. And I don't have to hit an extra CR at the end of the pasted area if it contains line ends.

Could it be an environment issue? The terminal emulator I use is iTerm on a Mac (version 3.4.8). I paste into both emacs and bash, on a variety of operating systems (FreeBSD, Mac, Linux, ...). And I cut from the terminal emulator and from web pages (using both Chrome and Safari).


----------



## _martin (Jul 14, 2021)

Spity Try adding this to your ~/.zshrc:

```
zle_highlight+=(paste:none)
```
Got it from here.

I used the ~/.inputrc because a) gdb is relying on it b) even bash is ok with that. But either terminal, shell, or even program (such as gdb with its readline dependency) can mess things up. zsh seems to have its own stuff ( e.g.  zshzle(1)).

Bracketed paste is not necessarily an evil but that highlighting is quite annoying (so one /me/ could benefit from bracketed paste and have highlighting disabled).


----------



## PMc (Jul 14, 2021)

ralphbsz said:


> For me, that exact use case works excellently pasting into emacs and into bash. And for emacs, it works even better than it used to, because when pasting code, the auto-indent turns itself off for pasted code. And I don't have to hit an extra CR at the end of the pasted area if it contains line ends.
> 
> Could it be an environment issue?


Strange, but no idea. I usually copy from xterm to xterm (x11/xterm).


----------

