> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.

As an university level educator: This is repeatedly a major hurdle for beginners, that makes the terminal (just text) feel like a different thing than just text to them. This and the fact that you can't just select the commands you have written with the mouse or with shift arrow makes beginners go mad, seemingly for no reason. And I count myself in there, I struggled with this for more than a year. When do you paste how? When donyou copy how?

The problem when you're learning this yourself is that you won't even have the correct vocabulary to describe what you want to know, it just feels like 99% of the world works and the 1% that doesn't is the terminal.

I get that this is historical, but if we want people to understand computers betond the consumer level this is literally like Blender changing from righ-click-select to left-click-select. Back then all the pros said it is no biggie just like you, but it turns out it was a biggie, because since then popularity exploded.

We terminal nerds lose nothing if more people understand terminals, quite the opposite.

▲

sam_bristow 6 days ago | parent | next [-]

It's a pain for even experienced users. Popping open the developer tools in the browser because you've done Ctrl-Shift-C is annoying, accidentally calling a group chat of 50 people in MS Teams for the same reason is really annoying.

	▲	PhilipRoman 6 days ago \| parent \| next [-]
		Ok as much as I like keyboard shortcuts, having a shortcut for making calls is just cruel. The ctrl-c thing isn't a big deal for me since I copy text to clipboard either using tmux (just selecting is enough) or piping the terminal screen to vim (where I've mapped it to just +)
	▲	grues-dinner 6 days ago \| parent \| prev [-]
		Oh thank God it's not just me. At least have a confirmation popup for that! Ctrl+Shift+C, Enter isn't exactly onerous for Teams power users.

▲

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

> that makes the terminal (just text) feel like a different thing than just text to them

Terminals are a lot more than just text. They were once physical machines. Now they are software emulating those old machines. These machines, physical or virtual, are controlled via in-band signaling. In many ways they are like extremely primitive browsers. Terminals are so old they actually predate copy paste.

> it just feels like 99% of the world works and the 1% that doesn't is the terminal

They don't actually work like all the other applications. They are completely different. Terminals are extremely complex legacy devices that require special kernel support to even work. The terminal line discipline is maintained by the kernel: Linux actually processes every single incoming and outgoing byte.

Nobody really expects to be able to paste text into a video game running inside a Super Nintendo emulator. Terminals are like that. It's actually amazing that modern terminal emulators were able to provide this feature.

> We terminal nerds lose nothing if more people understand terminals, quite the opposite.

Do you want people to actually understand terminals? To me it seems like you want to change terminals into something new that just happens to be easier to understand. They wouldn't really be terminals then, would they?

Things like ^C and ^D and ^[ are literally ASCII characters. Literally. Everything is ASCII text and that includes control characters, whose input is literally enabled by the Ctrl key. These bytes cause the terminal machine and sometimes even the kernel to do interesting things such as sending an interrupt signal to the slave program, closing its file descriptor or interpreting the next bytes as code in a sort of terminal instruction set. Typing on the keyboard just sends these codes into the system which can do any number of things in response.

We simply cannot have "normal" copy/paste with Ctrl-C and Ctrl-V. If we did this, terminals would no longer be the simple ASCII input devices described above.

Getting people to truly understand terminals means they have to understand all this.

▲

atoav 5 days ago | parent [-]

It may be a surprise to you, but there was nothing in your post that I didn't knew. I know all that. Just like I know the rationale behind Blender's Right-Click-select.

The terminal as a tool is shaped by its history, but that doesn't mean we have to carry that history with us forever, especially not at all cost. And I say that as someone who values history and has a self-designed physical terminal bell next to my desk. Does your terminal emulator strike a physical bell when you send BEL? If it does not than your terminal has moved on in time for one reason or another.

My point comes from the observation that the terminal is an extremely valuable tool to learn purely from an practical standpoint. Much more of that value comes from what it allows you to do, than from understanding how it works. Just like with Blender, where I as a former feelancer in VFX had no issue at all with right-click select, but occasional users would shake their fist at the heavens and complain about how bad Blender UI was with all its clever concepts. To them the historical understanding of the intricacies of the Blender UI and why "they are holding it wrong" would be utterly meaningless, what counts to them is that they can use the tool. And I agree.

Would I be happy with just any redesign of the terminal? No. But would I be okay if a good redisgn stopped it from working with physical type writers hooked up to main frames or from talking telnet to my oscilloscope? Yeah. I am okay with that. If I really need that there is probably software that still support that and I install that. I know that this is not a simple change, but it is 2025 and we can think about how things should be instead of staying with how they always have been without reason, especially if we are just talking about the defaults.

	▲	matheusmoreira 5 days ago \| parent [-]
		> It may be a surprise to you, but there was nothing in your post that I didn't knew. I know all that. Well, it is a surprise to me. You claimed terminals were "just text". You said you taught this to beginners. It is not surprising to me that those beginners would have difficulties understanding what was going on when terminals started demonstrating that they were indeed more complex than pure text. > But would I be okay if a good redisgn stopped it from working with physical type writers hooked up to main frames or from talking telnet to my oscilloscope? If we did that, they wouldn't be terminals anymore. They'd become some new, incompatible system that exists alongside the old school terminals. I'm not even opposed to it. I love the idea of reimagining and reinventing everything. We just gotta recognize that we're building new systems. The old ones should probably be left alone. Modern terminal emulators like kitty are working miracles out of this legacy stuff but they are still working within the confines of the system. > I know that this is not a simple change, but it is 2025 and we can think about how things should be instead of staying with how they always have been without reason, especially if we are just talking about the defaults. The legacy of terminals is useful even today. Embedded debugging interfaces use them. I wear a modern open source watch which supports a shell through the terminal system. There's just no getting rid of it. Even swapping Ctrl-C and Shift-Ctrl-C seems like we're just moving the inconsistencies around. Sure, copy paste is now consistent with modern interfaces but now the inputs no longer correspond directly to ASCII. Maybe we could have a vim-like modal interface where in GUI mode all the key combinations would do what we expect from modern systems while in terminal mode they would act like ASCII inputs. This fixes both inconsistencies... At the cost of being an error-prone modal interface.

▲

koiueo 6 days ago | parent | prev [-]

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