In ideal world I'd want to have consistent copy/paste. I'm not saying it's perfect now. I'm just arguing that there are bigger UX problems IMO.

BTW, text selection in terminals seems much more annoying to me, than the necessity to press Shift when copying.

▲

swiftcoder 6 days ago | parent [-]

That's kind of making the perfect-the-enemy-of-the-good. We can fix the copy/paste situation now, we can't necessarily fix the bigger problems so easily.

▲

koiueo 6 days ago | parent [-]

But what is the solution? I don't see it.

Doing meta+c/v like in mac?

Thanks, no. Meta is allocated for windows manipulations in all my setups, and I'm pretty confident the approach where modifier keys are tied to specific "layers" of functionality is a more sound approach

▲

trinix912 6 days ago | parent | next [-]

So we shouldn't go with the obvious solution that will also take the least effort to teach people (pressing the key next to Ctrl instead of Ctrl) because a few people out there have already set those shortcuts to do something magical on their machines?

▲

cycomanic 6 days ago | parent | next [-]

Why is that more obvious than simply adding the shift to all copy operations? Changing to use the windows/options key is a terrible idea.

Copy/paste would be the only operations to use the windows/options key inside of programs, so much for consistency! If we are talking about changing all keyboard shortcuts to use windows/option key instead of CTRL is even worse, you are suggesting we should suddenly change all shortcuts for everyone, because some people can't remember to press the shift in the terminal?

And then there's the fact that pretty much all window managers/desktops use the window/option key for window manipulation (which sort of makes sense). That's not a few people that is almost everyone using keyboard shortcuts of their desktop environment.

	▲	trinix912 6 days ago \| parent [-]
		If the aim is to have an elegant, OS-wide solution, changing it to the Windows/Meta key makes more sense semantically than keeping it in the realm of program-specific Ctrl shortcuts. Windows already has WinKey+V which brings up the clipboard manager. > If we are talking about changing all keyboard shortcuts to use windows/option key instead of CTRL is even worse, you are suggesting we should suddenly change all shortcuts for everyone, because some people can't remember to press the shift in the terminal? I only said that we should not subtract using Win/Meta key as an option just because some people have fancy setups that already use that. You implied the rest.

▲

koiueo 6 days ago | parent | prev [-]

Ctrl isn't near Cmd on my keyboard. And wasn't traditionally, even on first apple computers it resided where modern caps lock (an absolute waste of space) is.

Your solution is obvious to you, because you don't want to acknowledge the needs of others.

Alt+C/V, if anything, should be a better compromise, IMO. But it's still a compromise, not an obvious solution.

▲

swiftcoder 6 days ago | parent | prev | next [-]

Re the Mac like approach, I don't think that's actually all that incompatible. Yes, everyone would have to rejig their window manipulation a little, but keyboard shortcuts are a fundamentally different "layer" to ANSI escape sequences...

▲

koiueo 6 days ago | parent [-]

Totally agree on ANSI escape. But then to me windows manipulations is also an entirely different "layer".

Conceptually copy/paste could fit into that layer. It's like cross-window interface.

But what do we do with ctrl-z and ctrl-a, which are strictly text manipulation?

That's why Alt, IMO, would be a better modifier. And it all organizes into layers like this:

Ctrl - common ctrl sequences (like on Mac today)

Alt - app layer (still works for terminal UIs btw, even today)

Win - os/de/win layer

▲

trinix912 6 days ago | parent [-]

But wouldn't it make more sense to use the Win key for it than Alt? I think copy/paste could fit into the OS/DE layer.

	▲	koiueo 6 days ago \| parent [-]
		Maybe. It's borderline text-editing (the majority of usages are text, and probably within the same application). Also if we consider, how it's implemented: the app is responsible for content-type negotiation, if I copy a file in my file manager, it's the file manager's responsibility to yield file contents of I paste to another file manager, and yield the file:// uri if I paste to a text editor. So also border-line app functionality... As I said, I don't see an obvious solution, and even if I had full freedom to design everything from scratch, I don't know which option I'd pick.

▲

swiftcoder 6 days ago | parent | prev [-]

I should probably have said "give people the tools to solve". The solution in the OP won't work out of the box for most people, but it would let everyone with a programmable keyboard bind to whatever they like