I like how Apple introduced the CMD key, with copy/paste linked to it in the terminal, leaving CTRL to work as intended. Even outside the terminal basic emacs key binding work as intended, such as c-k c-u etc
We gonna get support for keys that don't exist on any modern keyboards, don't worry though you can remap them or bind them to change mplicated macro layers in your expensive mechanical keyboards.
Do all that and you won't need those two lines of xinit.rc
I use ctrl-Ins/shift-Ins and it works in my terminals and in the browser. I've not checked if it works in other apps because ctrl-c/ctrl-v always work in other apps. I'd be happy if ctrl-Ins/shift-Ins just always worked; I don't need innovation here.
The universality of copy/paste is overrated.
It's literally just adding shift in terminal emulators, no biggie.
A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...
And btw while apple is often offered as some golden standard for key bindings, I think the situation there is much (MUCH) worse: apps often intercept and handle common combinations on their own, with unclear precedence, which leads to non-deterministic behavior and a complete mess if you want to override any standard combination.
My biggest annoyance by far is that select on multiple browsers location bar does let you middle click paste the selection. You have to copy and paste.
> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.
> A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...
It occurs to me that if there were a universal copy/paste key, then it could be implemented by the OS rather than the applications, such that it uses a single clipboard (or chooses the appropriate one by application type, or even by user choice!) and sends an event (maybe as a signal?) to programs rather than having them scan. Which in turn would make it possible to remove the ability to scan, and thus the ability to have situations like that recent one with StarDict.
Much easier would be to have all apps treat C-S-C as copy and C-S-V as paste like the terminal does. In Chrome this starts the inspector. I changed jobs and went from a Mac to Linux and muscle memory keeps tripping me.
Been a linux user since 2016 when I found an Ubuntu 16 installation CD in a drawer wirh old books. The thing for me is having ctrl+v paste without formatting. (If I need to retain formatting, I will gladly do ctrl+shift+v)
Maybe it's just me but, I'd gladly scroll endlessly looking at pictures of old keyboards / HID devices. (I use a Fellows KU-9938 Split Keyboard and a Kensignton)
Not enough people know that you can just select text then middle click somewhere to paste it. No keys required and yes it works with all terminal emulators I've tried. This has been default behaviour on Linux desktops for as long as I've used it (decades).
> To trigger the copy or paste keyboard actions, software has to bind these key codes to actions. Software toolkits or apps themselves are responsible for this.
If only the universal subset of communication maintained by the OS were actual actions
While we're talking keyboards, what about emoji? Every messaging app has a different interface for them, some like Discord and Whatsapp allow you to use :smile: shortcuts, but the enumerated names are different across apps. I've occasionally gotten a dedicated OS emoji picker to show up on my Mac, but I don't know how.
On Ubuntu Cinnamon, I managed to create keyboard shortcuts for the 8 or so emoji I use the most by binding something called a "compose" key and modifying a .XCompose file, but it still took other config file gymnastics to make it persist between X sessions.
I think Apple did the right thing by keeping GUI shortcuts separate from terminal control codes.
I never understood why the Linux GUI world ran blindly after Windows and emulated every pattern, good or bad. And yes, I know that Ctrl-C/Ctrl-P for Copy/Paste are much older and came out of IBM's CUA and SAA initiatives. What matters is that with the Mac we had a clear role model how to handle this aspect of GUI cleanly but me missed it.
While we’re at it, I’m still on the lookout for IBM’s original SAA and CUA documentation. If anyone has these lying around, I’d be interested
Wouldn't it be darn nice, though, if there was a universal mechanism for apps to announce which shortcut they have available and a centralized way to configure them all?
For example, I was able to assign copy/paste keys to the corresponding actions in the GTK keybindings, and it worked like charm, except in Chrome. That is, in Chrome, web content respected these keybindings, but the browser UI didn't. So I could use the keys on textareas and inputs all I wanted, but paste into the address bar? Nooooo, BECAUSE FUCKING CHROME HAS THEM HARDCODED per platform!
(However, in Firefox it worked just fine across the whole UI.)
In Emacs if CUA mode is on, C-c behaves as copy if any text is selected (and if no other keys have been pressed within a short time). To send a C-c when text is selected you do a C-S-c instead. Similarly in Windows Terminal I remember C-c works as copy without any issue (it deselects the text with the first C-c IIRC, so if you do two C-c's with text selected you copy and then send an interrupt).
Do any linux terminals implement anything like this? Why resort to adding new keys to keyboards?
instead of some universal shortcuts, i would prefer to have another meta key, that we finally can do another-meta+ctrl+alt+ascii for more combinations :D
universal shortcuts are overrated and get in your way anyway :D
We already had a universal copy/paste in Linux: Mark with left mouse button, paste with middle button. This used to work for just about everything.
However, lately browsers started to ignore this when I mark the URL and try to paste it elsewhere, for example. Instead I get the old clipboard. I have to use the left button multiple times - and it works.
Falling back to Windows-style copy/paste, either with keys or pull-down menus with "copy" and later "paste" is, to me, a huge, inefficient step backwards and it's frustrating me every day.
Addon:
For purely non-mouse work, think serial terminal, I for one want Emacs bindings. Though that's typically configurable for the shell anyway, so everyone can choose what they prefer.
45 comments
[ 4.5 ms ] story [ 68.5 ms ] threadDo all that and you won't need those two lines of xinit.rc
The only issue is remembering to use Ctrl-C/V on Firefox, unless someone knows a way to remap its keybinds.
A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...
And btw while apple is often offered as some golden standard for key bindings, I think the situation there is much (MUCH) worse: apps often intercept and handle common combinations on their own, with unclear precedence, which leads to non-deterministic behavior and a complete mess if you want to override any standard combination.
You have to know what to add. Sometimes it is shift, sometimes (rxvt) it is alt.
> A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...
It occurs to me that if there were a universal copy/paste key, then it could be implemented by the OS rather than the applications, such that it uses a single clipboard (or chooses the appropriate one by application type, or even by user choice!) and sends an event (maybe as a signal?) to programs rather than having them scan. Which in turn would make it possible to remove the ability to scan, and thus the ability to have situations like that recent one with StarDict.
Maybe it's just me but, I'd gladly scroll endlessly looking at pictures of old keyboards / HID devices. (I use a Fellows KU-9938 Split Keyboard and a Kensignton)
If only the universal subset of communication maintained by the OS were actual actions
I use copy/paste more than I use interrupt.
I hated MacOS keyboard shortcuts at first, but cmd-c/cmd-v do work around this problem.
On Ubuntu Cinnamon, I managed to create keyboard shortcuts for the 8 or so emoji I use the most by binding something called a "compose" key and modifying a .XCompose file, but it still took other config file gymnastics to make it persist between X sessions.
I never understood why the Linux GUI world ran blindly after Windows and emulated every pattern, good or bad. And yes, I know that Ctrl-C/Ctrl-P for Copy/Paste are much older and came out of IBM's CUA and SAA initiatives. What matters is that with the Mac we had a clear role model how to handle this aspect of GUI cleanly but me missed it.
While we’re at it, I’m still on the lookout for IBM’s original SAA and CUA documentation. If anyone has these lying around, I’d be interested
I think of control-c/control-v as windows copy/paste
but on macos I can use command-c/command-v in terminals no problem.
For example, I was able to assign copy/paste keys to the corresponding actions in the GTK keybindings, and it worked like charm, except in Chrome. That is, in Chrome, web content respected these keybindings, but the browser UI didn't. So I could use the keys on textareas and inputs all I wanted, but paste into the address bar? Nooooo, BECAUSE FUCKING CHROME HAS THEM HARDCODED per platform!
(However, in Firefox it worked just fine across the whole UI.)
Do any linux terminals implement anything like this? Why resort to adding new keys to keyboards?
universal shortcuts are overrated and get in your way anyway :D
Addon: For purely non-mouse work, think serial terminal, I for one want Emacs bindings. Though that's typically configurable for the shell anyway, so everyone can choose what they prefer.
You can bind these on Emacs, for example.
So I ran xev to see what buttons they mapped to, and chose:
"xvkbd -text "\[XF86Copy]"" m:0x0 + b:8 "xvkbd -text "\[XF86Paste]"" m:0x0 + b:9
which my fingers have learned work everywhere except Chrome. Thanks, Google.