On Wed, 18 Nov 2020 10:11:12 +0100
Ludovic Bellière <belliere.ludovic@???> wrote:

> Hey Steve,
>
> I believe you have some misconception on how cut and paste
> works on the X Window environment. I believe that a proper
> understanding on how you host environment behave would help you figure
> out an appropriate workflow.

Yes!



> Whenever you select something, the content is then sent to the PRIMARY
> selection. As such, selecting text would be the equivalent of MS
> Windows's CTRL-C. Content is then accessed using the middle mouse
> button.

And sometimes Shift+Ins. And if I run the copyq clipboard manager,
Shift+Ins becomes more of a middle click synonym.

>
> Whenever the user specifically request the content to be copied, with
> CTRL-C, the content would then be sent to the CLIPBOARD selection.
> Accessed then using CTRL-V.

Yes. However, Ctrl+C doesn't work everywhere. It doesn't work in gVim or
xterm. Ctrl+c seems to be a feature that must be built into the source
application.

>
> There can be any number of selections (ie. buffers containing your
> data), but we usually needs to take care of only three: PRIMARY,
> SECONDARY and CLIPBOARD.

Yes, thanks to you I know this now.

>
> Writing this email, whenever I select some text it then becomes
> available across all windows through the click of the middle mouse
> button so long the text remains selected. If I want a more permanent
> buffer, I would then need to use CTRL-C.

If Ctrl+C is available. More on how to get past lack of Ctrl+C later in
this email.

> See: https://tronche.com/gui/x/icccm/sec-2.html#s-2.6

Wow, that's a complicated document describing a complicated process. No
wonder I've been having problems.

>
> There is another behavior called cut buffers. Cut buffers store data
> regardless of the state of the window from which it originates. These
> behave like the PRIMARY selection, selecting text would then send the
> content to a cut buffer. I believe terminals, such as xterm, make use
> of the cut buffer mechanism. The guake terminal, however, does not and
> uses the PRIMARY selection instead without clearing it after the text
> is no longer highlighted.
>
> See: https://tronche.com/gui/x/icccm/sec-3.html#s-3

:-) To much, for me! I don't understand a word of it.

>
> > I've tried pastebin managers in the past, but they seemed to make
> > things worse.
> >
> > If anybody knows of a pastebin manager (but not associated with KDE)
> > that makes cut and paste on any Linux X (not associated with a
> > specific wm/de (Window Manager/Desktop Environment)), please let me
> > know.
> >
>
> That does not exists per say. The clipboard is managed by the X window
> system for very good reason, one of them is to enable the copied
> content to be shared between applications. The behavior of the
> clipboard may be different depending on what takes ownership of it,
> which is why you may have found different behavior with different set
> of software.
>
> Different software can take ownership of the selections, and those
> software can behave differently. For instance claws-mail will purge
> the PRIMARY selection whenever I stop selecting text within the
> window, where as guake will not. That can lead to some weird stuff.
>
> For instance:
> - I select text within xterm -> sent to a cut buffer and PRIMARY
> - Cut buffers are not available within claws mail, PRIMARY is.
> - I select something in claws mail, PRIMARY gets cleared
> - The content of the cut buffer is still available to xterm, so long
> PRIMARY is empty.

The preceding 4 bullet points were exactly why I called Linux cut and
paste "sucky." One needs to know tremendous amounts of context, or
do much too much trial and error, to successfully cut and paste in
Linux.

>
> As for the clipboard manager, I use xfce4-clipman. It handle the
> CTRL-C requests and store a history. Leaves the PRIMARY selection
> alone. There is also a xclipboard, but that software changes the
> behavior of the selections.

Your descriptions of the various places storing information is helpful.
A lot of where information will be depends on the source application,
as you explained. From my perspective, multiple places to store that
info is a disadvantage, not an advantage. If need be, I can manage
multiple snippets myself, by pasting them in temporary places.

I've been testing out various clipboard managers, and I've found one
called copyq. So far, it seems to put most everything in what you call
the clipboard, pasteable with Ctrl+V (if the destination responds to
Ctrl+V). Subjectively, I find a lot less confusion for myself if copyq
is running. I use the runit init, so I'll probably make copyq a daemon
that runs on boot, is controllable and inspectable with the sv command.


>
> >

> > > Also:  a lot of mouses have a middle scroll button that doubles as
> > > a middle clickable button.  There can be a mechanical problem
> > > here; when I click on my middle button, I sometimes get a click,
> > > sometimes one step of a scroll (usually upwards), and sometimes
> > > both. Annoying.  It takes come carefulness to get the signal I
> > > want.    

> >
> > Yes. You need to press straight down, with absolutely no hint of
> > pressure up or down, left or right. Cutting and pasting shouldn't be
> > this hard.
> >
>
> Smells like a hardware problem to me. A click needs to feel like a
> click, not a breeze.

That's not what I meant. It's just difficult to press down on a wheel
in such a way that it pushes in rather than rotates, angles to the left
or right. In other words, on many mice, the physical resistance of
wheel turning is the same or less than that of pushing it in, which
requires utmost attention from the user. And don't forget, a mouse can
both click *and* rotate.

Thanks to all of you who gave me information. I feel much more
comfortable using Linux cut and paste than I did when I woke up this
morning.

SteveT

Steve Litt
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive