In all GUI text editors, web browsers and IDE's you can move a cursor:
- left/right arrows - move by char;
- ctrl+left/right - move by word;
- home/end - move to start/end of line.
Add Shift to any of above combination and everything you jumped through now is selected and you can: Ctrl+C, Ctrl+X,Delete to copy/cut/delete selection.
Also, you can Ctrl+Delete and Ctrl+Backspace to delete a next/previous word.
Also, you can Ctrl+Home/End to jump to start of first line or end of last line.
I want this to work when I type in a command in my Terminal.
Is it possible in Linux? It's a vanilla experience in Windows+Powershell, thanks to default PSReadlLine extension. It works both in conhost.exe and in Windows Terminal, but doesn't work in WT + cmd.exe, which makes me think it's PSReadLine which is responsible for this technological perfection.
"But you can't copy with Ctrl+C, it's..." - You can. When something is selected It copies selection to clipboard, otherwise it sends SIGINT.
I'm not bound to any distro or terminal application, but right now I don't see these incredible text editing techniques working even in Ubuntu+Powershell+PSReadLine, to say nothing about the Bash. I've tried installing WezTerm, but it doesn't have text selection either, at least by default. And I'm inclined to think it has nothing to do with terminal emulators at all, since it works in conhost.exe+Powershell.
I think this is one of many un-features in Linux world where
As such, for you individually, I suggest just getting more comfortable with tmux (or zellij) and vi-like keybinds for text manipulation. Once you learn those (and set your readline mode to
vi), you won't look back. Oh, also, tryCtrl+x Ctrl+ein bash, it might help.Or switch to emacs and using it as a terminal emulator. In that case you will have to learn and use emacs keybindings, but the selection semantics in the "terminal" will be the same as in the "editor".
What exactly? Shift-selection is already possible with Blesh. I think I've seen scripts for synchronizing buffer with clipboard. And everything else is a matter of redefining existing shortcuts.
I've heard about Linux being highly customizable and decentralized OS, and suddenly I can't define my own shortcuts because there is a list of un-features?
I don't care about Vi and Emacs, I already have my workflow and I'm trying to transfer it to Linux. When I will succeed, then (maybe) I will spend some time to explore other ways of interacting with terminal. Otherwise, it's not freedom, it's becoming a victim of OS.
You can customize it to do whatever you want. Heck, you can write your own terminal emulator that does exactly what you need. But some things can be harder to do than others and require skills and experience. Once someone implements those harder things, they become a "feature". Before then, therefore, they are an "un-feature". See https://xkcd.com/1349/
E.g. it is probably possible to set up your shell to use shift-selection for the command you're currently editing, but shift-selection for the output of a previous command will require terminal support. You will have to make sure that the two don't interfere with each other, which can be quite complicated.
Linux is a different OS that, by default, does things differently from others. You can configure it to emulate some other UX, but it won't necessarily be easy. In the meantime, you can install the
microeditor, setEDITOR=micro, and then Ctrl+x Ctrl+e in bash to edit the command in a more familiar setting.I'm fine, I got what I wanted. Apparently, it isn't un-feature of Linux, it's un-feature of ReadLine which is shipped with Bash.
Add Windows-like Alt codes to the list. They're not perfect (they use a DOS codepage and A-F in the Unicode extension clash with shortcuts in other programs like Firefox, although not passing them through via xkb would solve this) but people use them a lot, especially in my country. At? Alt+64. Backtick? Alt+96. Caret? Alt+94. Hash? Alt+38. Musical note? Alt+13. Yes, we can type most of these on the Czech layout with AltGr but people don't know this and/or prefer things that work on the commonly default English layout too.
I prefer compose keys because they are easier to remember.
Oh, also, I think GTK apps have that Ctrl+shift+U thing which allows you to enter characters by code. Never really got used to it though.
I'm getting used to Compose and AltGr. Unexpected Keyboard for Android helps learn compose codes by visualizing them but it's still a bit of resistance. And yes, Compose can also be used to input Unicode hex codes.
Either way, I created a custom layout for AltGr and Shift+AltGr layers that is more convenient for me than remembering Compose and Unicode codes.