[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian 11.1, xfce4-terminal, select entire line, middle-click, newline not pasted



On Sun 05 Dec 2021 at 19:46:57 (-0800), Mike Kupfer wrote:
> David Christensen wrote:
> 
> > On Debian 9 (and 10, and earlier?) with Xfce Terminal, when I select
> > an entire line of text in one terminal and then middle click paste in
> > another terminal window, the entire line is pasted; including the
> > newline.
> [...]
> > On Debian 11,  when I select an entire line of text in one terminal
> > and then middle click paste in another terminal window, the line is
> > pasted without the newline; requiring me to select the target window
> > and press <Return>.
> 
> If you use bash,
> https://utcc.utoronto.ca/~cks/space/blog/unix/BashBracketedPasteChange
> probably explains what you're seeing.

Interesting, so I thought I'd try it out. Running buster at present,
bash is 5.0.3(1)-release, and I take it that the default is unchanged.

So I added   set enable-bracketed-paste on   to ~/.inputrc
and removed   XTerm*cutNewline: false   from ~/.Xresources
and restarted X.

The effect is as it says: if I triple-click on a line and then
paste it at a bash prompt, the line is pasted complete with the
newline. So the cursor is now at the start of the next (blank)
line, and can be scrolled back, with Left, into the text of the
unexecuted commandline.

With   set enable-bracketed-paste off   and   XTerm*cutNewline: true
the cursor would still be located at the end of the commandline.

(I've never seen any effects of highlighting being carried from
the copied text into the pasted text, as discussed in the link.
Perhaps that only comes with bash 5.1.)

There are two things that make me prefer the method I'm used to:

1) If you paste a triple-clicked line into the middle of a
commandline, you've now got to rubout the spurious newline
that was just added as part of the paste.

2) A pasted commandline sitting there with the cursor at the
beginning of the next line is visually indistinguishable from
a command that's busy working (or stuck in a loop) without
having produced any output. The only way you can tell them
apart is by pressing Left, and seeing whether the cursor
moves back to the previous line, or else vomits ^[[D.

Are there any benefits? The only one I've thought of is that
if you accidentally paste a chunk of plain text into a bash
prompt, you get a chance to remove it all before bash tries
to execute it. Without bracketed paste, bash would immediately
try to execute each and every line of the pasted text—oops.

So I have reverted to my   XTerm*cutNewline: false
but will stick with bracketed paste for a while just to see
whether I notice any other benefits.

Cheers,
David.


Reply to: