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] problematic mouse driver?
On Wed, Nov 18, 2020 at 10:58:16AM -0800, Ian Zimmerman wrote: > On 2020-11-17 06:07, Haines Brown wrote: > > > About the time I upgraded to Bwowulf I experienced periodic problems > > having the mouse pasting scanneted text with middle mouse button. > > > It does help to have a full leo^H^H^Hkeyboard with a numeric keypad, > rather than one of the built-in laptop keyboards. Some decent laptops have full numeric keypads: Clevo for instance. ael ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] problematic mouse driver?
On 2020-11-17 06:07, Haines Brown wrote: > About the time I upgraded to Bwowulf I experienced periodic problems > having the mouse pasting scanneted text with middle mouse button. Do people in this thread know about PointerKeys, and that it is an honest X11 feature, not something added by Gnome or KDE etc.? In my xsession script I have (indirectly through sourcing): setxkbmap -option shift:both_capslock -option caps:menu -option \ compose:sclk -option keypad:pointerkeys It does help to have a full leo^H^H^Hkeyboard with a numeric keypad, rather than one of the built-in laptop keyboards. -- Ian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Who is disabling core dumps?
On 18/11/2020 13:38, tito via Dng wrote: On Wed, 18 Nov 2020 12:10:19 +0100 Alessandro Vesely via Dng wrote: I enabled core dumps in /etc/security/limits.d/coredump.conf (* - core unlimited); core_pattern and suid_dumpable are set appropriately. However, most processes have a soft limit of 0; that is, core dump disabled: # for p in $(ps -e -o pid| tail -n +1); do prlimit --noheadings --core --pid $p 2>/dev/null; done | sort |uniq -c 1 CORE max core file size00 bytes 260 CORE max core file size0 unlimited bytes 44 CORE max core file size unlimited unlimited bytes Only 44 processes have coredump enabled. Why? I looked for 'ulimit' in /etc/init.d, .bashrc's, and other starters, but found nothing relevant. The one with hard limit 0 is ssh-agent, presumably set by the program itself for obvious security reasons. Who is soft-disabling core dumps for the other 260? Apparmor? Hmm... I have apparmor=0 in GRUB_CMDLINE_LINUX, but still have an apparmor script in /etc/init.d. Can it still bite? Curiously, the shell in the root terminal window had 0. But all daemons were already started by the time I could put my fingers on a shell's input. Best Ale -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Who is disabling core dumps?
On Wed, 18 Nov 2020 12:10:19 +0100 Alessandro Vesely via Dng wrote: > Hi all, > > I enabled core dumps in /etc/security/limits.d/coredump.conf (* - > core unlimited); core_pattern and suid_dumpable are set > appropriately. However, most processes have a soft limit of 0; that > is, core dump disabled: > > # for p in $(ps -e -o pid| tail -n +1); do prlimit --noheadings > --core --pid $p 2>/dev/null; done | sort |uniq -c 1 CORE max core > file size00 bytes 260 CORE max core file size0 > unlimited bytes 44 CORE max core file size unlimited unlimited > bytes > > Only 44 processes have coredump enabled. Why? I looked for 'ulimit' > in /etc/init.d, .bashrc's, and other starters, but found nothing > relevant. > > The one with hard limit 0 is ssh-agent, presumably set by the program > itself for obvious security reasons. > > Who is soft-disabling core dumps for the other 260? > > Is there a better way to enable them, other than for each process? > > > Best > Ale Apparmor? Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] clipboard manager: was: problematic mouse driver?
Στις 18/11/20 2:07 μ.μ., ο/η al3xu5 / dotcommon έγραψε: 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. was using clipit before, but clipit in debian/devuan nowadays (testing/ceres), just depends on diodon+zeitgeist-core and will probably be removed completely from repos in bullseye/chimaera.. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909309#60 in anycase, i wouldn't add a ppa just to keep clipit (which was nice when working..), there are many alternatives around.. :) d. ___ 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?
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
[DNG] Who is disabling core dumps?
Hi all, I enabled core dumps in /etc/security/limits.d/coredump.conf (* - core unlimited); core_pattern and suid_dumpable are set appropriately. However, most processes have a soft limit of 0; that is, core dump disabled: # for p in $(ps -e -o pid| tail -n +1); do prlimit --noheadings --core --pid $p 2>/dev/null; done | sort |uniq -c 1 CORE max core file size00 bytes 260 CORE max core file size0 unlimited bytes 44 CORE max core file size unlimited unlimited bytes Only 44 processes have coredump enabled. Why? I looked for 'ulimit' in /etc/init.d, .bashrc's, and other starters, but found nothing relevant. The one with hard limit 0 is ssh-agent, presumably set by the program itself for obvious security reasons. Who is soft-disabling core dumps for the other 260? Is there a better way to enable them, other than for each process? Best Ale -- ___ 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] problematic mouse driver?
Le 18/11/2020 à 00:50, Hendrik Boom a écrit : > On Tue, Nov 17, 2020 at 05:54:45PM -0500, Haines Brown wrote: >> I infer from those kind enough to answer that my problem getting the >> mouse to paste what it scanned is not unusual. When the problem shows >> up again I'll try to paste with both mouse buttons rather than the >> button. > I've always had difficulty pressing both buttons close enough that the > computer recognises them as being at the same time. Also, I think there's > some kind of mouse configuration that is required for this to work. > > -- hendrik > I never had this problem - for decades. Neither with mouses nor with the touchpad of my laptop, on which I need to click both buttons to emulate the central one. I'd suggest buying a new mouse. Cut-and-paste problems exist though. Cuting in a text processor like libreoffice records some markup. When I don't want it, I first paste into an xterm or into Emacs, and then cut again. Simple mouse-cut does not paste into (eg) Scribus; you need to cut the text from some application which handles Ctrl-C,or a menu-cut eg a web browser. -- 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?
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
