Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Steve: > On Thu, 19 Nov 2020 22:16:46 +0100 > a...@saar.de wrote: > > Please, in all your critique of X's mechanism in doing cut&paste > > remember, that all this worked quite well until around 2000, when > > (mostly) KDE and Gnome started to try to make Linux more and more > > like Windows and ignoring and sidelining established mechanisms. > > That's not how I remember it. When I first started using Linux in 1998, > RH 5.0, with fvwm user interface, cut and paste sucked. "Sucked" is a somewhat fuzzy thing and it also depends on whatever you expected in 1998, my guess is that you didn't like the middle click thing, while others like it. As it stands today, we have two somewhat colliding ways to do cut'n'paste in linux+X. Regards, /Karl Hammar ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
On Thu, 19 Nov 2020 22:16:46 +0100 a...@saar.de wrote: > Please, in all your critique of X's mechanism in doing cut&paste > remember, that all this worked quite well until around 2000, when > (mostly) KDE and Gnome started to try to make Linux more and more > like Windows and ignoring and sidelining established mechanisms. That's not how I remember it. When I first started using Linux in 1998, RH 5.0, with fvwm user interface, cut and paste sucked. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Moin... In article <20201118204631.28512...@mydesk.domain.cxm> you write: >On Wed, 18 Nov 2020 10:11:12 +0100 >Ludovic Bellière wrote: >> > > 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. Please, in all your critique of X's mechanism in doing cut&paste remember, that all this worked quite well until around 2000, when (mostly) KDE and Gnome started to try to make Linux more and more like Windows and ignoring and sidelining established mechanisms. This of course was not improved by the introduction of the mouse wheel instead of the middle mouse button (which the other 2 do not use). So, what about introducing a patch suppressing any mouse wheel rotation while clicking - if that is not already configurable... >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. I knew about these details somewhere in the back of my brain for a long time - although I never really needed them as long as most applications behaved consistently. What about standardizing around the old X interface and collecting information about programs behaving correct along these lines? cu AW -- [...] If you don't want to be restricted, don't agree to it. If you are coerced, comply as much as you must to protect yourself, just don't support it. Noone can free you but yourself. (crag, on Debian Planet) Arne Wichmann (a...@saar.de) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Le 20/11/2020 à 11:22, Ludovic Bellière a écrit : > vim, just like emacs, is an old software using old paradigms. They use > their own buffers to copy and paste content, unrelated to the X window > system. They can be made to store the text to an external buffer though. Nevertheless, under many applications like Emacs, Lyx, and I guess Vim, the primary X-window buffer substitutes to keyboard input when pressing the central button. Which doesn't work on Scribus. In Firefox it does substitute, but not everywhere, eg when you're asked to enter twice your email address. Seems there is something in html forms which allows to select different behaviours for different fields. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Hi Ludovic, Ludovic Bellière writes: > [...] > > vim, just like emacs, is an old software using old paradigms. They use > their own buffers to copy and paste content, unrelated to the X window > system. They can be made to store the text to an external buffer though. I've found that highlighting in Emacs and using C-w to remove (and C-_ to restore) will make the "copied" text pastable with Ctrl-V in chromium and firefox, and probably other GUI applications, and with Shift-Ctrl-V on guake terminals. Conversely, using Shift-Ctrl-C on guake and Ctrl-C with my browsers will let me C-y that into Emacs. # BTW, marking with C-@ in Emacs and moving the cursor can also be used # to "highlight". > xterm doesn't have CTRL-C because that shortcut can potentially be used > by the terminal itself. (i.e. will kill the running process.) Understandable and I guess that's why guake uses Shift+Ctrl-C. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
On Wed, 18 Nov 2020 20:46:31 -0500 Steve Litt wrote: > 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. Using the X window system, highlighting text puts it in the PRIMARY selection. On windows, highlighting text does nothing. Using the X window system, highlighting text then pressing CTRL-C puts the content into the CLIPBOARD selection. On windows, though, that action puts the text into the PRIMARY selection. vim, just like emacs, is an old software using old paradigms. They use their own buffers to copy and paste content, unrelated to the X window system. They can be made to store the text to an external buffer though. xterm doesn't have CTRL-C because that shortcut can potentially be used by the terminal itself. (i.e. will kill the running process.) See: - https://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_01.html - https://tiswww.case.edu/php/chet/readline/rluserman.html pgpq3YZm6eaQE.pgp Description: Signature digitale OpenPGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
On Thu, 19 Nov 2020 09:35:30 +0100 Didier Kryn wrote: > Thanks a lot for these detailed explanations, though it's missing > how the SECONDARY is used. The way we use software on the GNU/Linux environment involve a lot of bash. That has to be taken into account in the design of the environment. Pasting from the document I linked: 2.6.1.2. The SECONDARY Selection The selection named by the atom SECONDARY is used: * As the second argument to commands taking two arguments (for example, "exchange primary and secondary selections") * As a means of obtaining data when there is a primary selection and the user does not want to disturb it > AFAIR , Windows doesn't allow cut/paste across different > applications. But I confess I didn't use this OS for decades. You remember wrong. pgpXpZrdhTeTc.pgp Description: Signature digitale OpenPGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Le 18/11/2020 à 10:11, Ludovic Bellière a écrit : > 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. > > 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. > > 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. > > 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. > > See: https://tronche.com/gui/x/icccm/sec-2.html#s-2.6 > > 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 > >> 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. > > 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. > Thanks a lot for these detailed explanations, though it's missing how the SECONDARY is used. A lot needs to be studied to understand the behaviour of cut/paste. Since most of us only use a finite number of applications, it therefore seems easier to rely on an empirical knowledge of the behaviour of each app. AFAIR , Windows doesn't allow cut/paste across different applications. But I confess I didn't use this OS for decades. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
On Wed, 18 Nov 2020 10:11:12 +0100 Ludovic Bellière 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
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Wed, 18 Nov 2020 10:40:03 +0200 - "Dimitris T." : > you probably mean clipboard manager(?)... > i'm using parcellite mainly for that. gtk based, but also ran it in LXQT > without issues iirc... There is also ClipIt (forked from Parcellite, adding bugfixes and features). I do not use neither parcellite nor clipit, so do not know how it is good. project: https://github.com/CristianHenzel/ClipIt debs: http://ppa.launchpad.net/afelinczak/ppa/ubuntu/pool/main/c/clipit/ Regards al3xu5 -- Say NO to copyright, patents, trademarks and industrial design restrictions! Public GPG/PGP key: F94CFE23 (4096 bit RSA) Key fingerprint:59C6 9DC7 CD4B CF2F A190 E3DE 69C5 977B F94C FE23 pgpnoUoCy26Id.pgp Description: Firma digitale OpenPGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Ludovic Bellière - 18.11.20, 10:11:12 CET: > 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. Oh, and thanks for your detailed explanation. It goes deeper than what I read in a long time about it. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Ludovic Bellière - 18.11.20, 10:11:12 CET: > On Tue, 17 Nov 2020 19:07:06 -0500 > > Steve Litt wrote: > > On Tue, 17 Nov 2020 08:16:11 -0500 > > Hendrik Boom wrote: > > > > Other than deliberate exclusion of Linux users by Microsoft and > > their > > henchmen, the only area I've seen where Windows is better than Linux > > is cut and paste. On Windows, it's Ctrl+C, Ctrl+V, and IIRC that > > works seamlessly on both CLI and GUI. On Linux, it can be Ctrl+C > > and Ctrl+V, or highlight and middle mouse button (be sure to press > > and not turn at all), or menu edit and paste, or who knows what > > else. I hate, hate, HATE it: It deeply cuts into my daily workflow. > > 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. > > 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. > > 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. Plasma's Klipper has a functionality to unify some of this. It is an option to unify clipboard and actual selection. I bet this may refer to CLIPBOARD and PRIMARY selection. I enabled this option and it works most of the time. It is still not perfect though. I heard that with Wayland there is just one clipboard. I also really like the functionality that Klipper can store the last N selections or clipboard entries and I can still access them. You can also delete all of just one selection, for example if you copied a password. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
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. On Tue, 17 Nov 2020 19:07:06 -0500 Steve Litt wrote: > On Tue, 17 Nov 2020 08:16:11 -0500 > Hendrik Boom wrote: > > Other than deliberate exclusion of Linux users by Microsoft and their > henchmen, the only area I've seen where Windows is better than Linux > is cut and paste. On Windows, it's Ctrl+C, Ctrl+V, and IIRC that works > seamlessly on both CLI and GUI. On Linux, it can be Ctrl+C and Ctrl+V, > or highlight and middle mouse button (be sure to press and not turn at > all), or menu edit and paste, or who knows what else. I hate, hate, > HATE it: It deeply cuts into my daily workflow. > 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. 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. 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. 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. See: https://tronche.com/gui/x/icccm/sec-2.html#s-2.6 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 > 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. 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. > > > 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. Cheers, Ludovic pgpN1dzHLBUuo.pgp Description: Signature digitale OpenPGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Steve Litt wrote: > 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. you probably mean clipboard manager(?)... i'm using parcellite mainly for that. gtk based, but also ran it in LXQT without issues iirc... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
On Wed, 18 Nov 2020 08:58:58 +0100 Pontus Goffe via Dng wrote: > On 2020-11-18 08:23, d...@d404.nl wrote: > > > > In my XFCE environment I use Ctrl+Ins to copy and Shift+Ins to paste > > most of the time instead of Ctrl+C and Ctlr+V. > > > > Grtz > > > > Nick > > > I use that a lot too and I am on LXDE. > Whats funny is that this is something I brought with me from really > old Windows but I dont think it was invented there. > It is the only sequence I know that work in most scenarios. Ctrl-C is > not a great thing for copying in terminals. > //PG The ergonomics of this is awful, being a 2 hand command with both hands leaving home position (or the mouse if you're using a mouse-favoring application). But... This is the first decent tool I've found for copying *out* of Vim and into anything else. Just copy in Vim as if you'll later paste in the same file, but press Shift-Ins in the other application to paste it into that other application. So thanks! SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
On 2020-11-18 08:23, d...@d404.nl wrote: In my XFCE environment I use Ctrl+Ins to copy and Shift+Ins to paste most of the time instead of Ctrl+C and Ctlr+V. Grtz Nick I use that a lot too and I am on LXDE. Whats funny is that this is something I brought with me from really old Windows but I dont think it was invented there. It is the only sequence I know that work in most scenarios. Ctrl-C is not a great thing for copying in terminals. //PG ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
On 18-11-2020 01:07, Steve Litt wrote: > On Tue, 17 Nov 2020 08:16:11 -0500 > Hendrik Boom wrote: > > >> A wild guess. Linux has over the ages acquired (at least) two cut >> and paste mechanisms -- one from the underlying X system, and another >> from the desktop systems put on top. They don't always agree as to >> what has to be cut and pasted; I suspect each has its own paste >> buffer. They oftern communicate but not always. There have been >> occasions where I have had to cut in one pieve of software, paste >> into emacs, and then cut from emacs with the other mechanism and >> paste where I intended originally. > Other than deliberate exclusion of Linux users by Microsoft and their > henchmen, the only area I've seen where Windows is better than Linux is > cut and paste. On Windows, it's Ctrl+C, Ctrl+V, and IIRC that works > seamlessly on both CLI and GUI. On Linux, it can be Ctrl+C and Ctrl+V, > or highlight and middle mouse button (be sure to press and not turn at > all), or menu edit and paste, or who knows what else. I hate, hate, > HATE it: It deeply cuts into my daily workflow. > > 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. > > >> 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. > > SteveT > > Steve Litt > Autumn 2020 featured book: Thriving in Tough Times > http://www.troubleshooters.com/thrive > ___ In my XFCE environment I use Ctrl+Ins to copy and Shift+Ins to paste most of the time instead of Ctrl+C and Ctlr+V. Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Linux's sucky cut and paste: was: problematic mouse driver?
On Tue, 17 Nov 2020 08:16:11 -0500 Hendrik Boom wrote: > A wild guess. Linux has over the ages acquired (at least) two cut > and paste mechanisms -- one from the underlying X system, and another > from the desktop systems put on top. They don't always agree as to > what has to be cut and pasted; I suspect each has its own paste > buffer. They oftern communicate but not always. There have been > occasions where I have had to cut in one pieve of software, paste > into emacs, and then cut from emacs with the other mechanism and > paste where I intended originally. Other than deliberate exclusion of Linux users by Microsoft and their henchmen, the only area I've seen where Windows is better than Linux is cut and paste. On Windows, it's Ctrl+C, Ctrl+V, and IIRC that works seamlessly on both CLI and GUI. On Linux, it can be Ctrl+C and Ctrl+V, or highlight and middle mouse button (be sure to press and not turn at all), or menu edit and paste, or who knows what else. I hate, hate, HATE it: It deeply cuts into my daily workflow. 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. > 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. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
