gnome-terminal changing paste shortcut ctrl+shift+v to shift+ins
So, being frustrated with a firefox addons copy not showing up with shift+ins in gnome-terminal I decided to switch gnome-terminal paste shortcut to shift+ins.
Are there any known bugs with doing this? I’ve only done some quick tests and seem to always get the clipboard info I’m expecting.
edit: Thanks to @lemmyng I now know about gpaste and use that to sync primary and selection both ways.
Muscle memory!
As soon as I work in a terminal I use shift+ins instinctively, most programs still send the copy to both buffers if they have a “copy” button/function but some now only send to primary and you get some old text selection thrown into your terminal instead of the command the program helpfully copied for you.
Shift/Ctrl+Ins/Del unite! 😁 And yes, muscle memory is a powerful drug. Been using it since before Windows came along, kept using it after. Especially useful after I switched to Dvorak (and yes, I know of Colemak).
Shift+Ins was the default paste on Windows 3.0, before Apple sued Microsoft for copying their OS (back in then it was still called just “System”), so MS added Ctrl+C for Windows 3.1, but the old one still work.
Same thing for Xorg. Ctrl+Ins for copy, Ctrl+Del for paste and Ctrl+Ins for paste.
Bugs? No, works as intended. But you might want to consider a clipboard manager instead, so that you can sync the clipboard to the selection buffer and vice versa.
I’ve tried finding a manager for this, Pano allows me to sync primary to selection but not selection to primary but I haven’t found one that works the other way around. I’m currently running Fedora 38 with Gnome 44.
While the shift+ins helps with pasting the wrong stuff it would be even better if I could get middle-click to sync up too.
They wouldn’t let you change the shortcut if changing the shortcut didn’t work. You can even do Ctrl+C and Ctrl+V if you want, but then ^C and ^V wouldn’t be passed to the terminal anymore. The shortcuts take priority.
Add comment