I rarely ever use Ctrl-r since I usually know the starting part of the command I want. So, I type those starting characters and use up/down arrow keys, courtesy these lines in `~/.inputrc`
> I was using Control-A and Control-K a lot on the command line to jump to the beginning of the line, and then erase the rest of the line and tried it once somewhere else and it worked!
This is the behavior of emacs; I'm very happy as I spend most of my time in a terminal window that I can use c- shortcuts both in emacs and in the OS natively.
It goes way beyond that though: if command’s in a shortcut it pretty much guarantees that’s an application / system shortcut, which frees Ctrl to only deal with text control (and literal control codes in the shell).
And thus Option essentially only does alternate characters.
It’s not perfect, mind, for instance the number of keychords means emacs is annoying whether you leave meta on option or move it to command.
> Ideally this is just one command, I think, like Cmd/Ctrl+L for "select current line". :)
I find it easier to, instead of remember another command, remember "jump to start of line, select entire line."
Mentally composable and it works in all text input boxes across the entire system. (MacOS, cmd-l selects current line in VS-Code, jumps to URL bar in Chrome.)
IMHO the problem is getting stuff to be system wide. Per editor hotkeys, or even worse. hotkeys added by plugins, cause dissonance when I sit down at someone else's computer, or just switch apps.
> One of the most common use cases for the `ctrl` key is COPYING shit and followed by PASTING shit and it DOES NOT WORK in a fucking TERMINAL... Because `ctrl-c` sends an interrupt
Most terminals today have a copy-on-select feature, which means you don't need to ctrl-c at all. Just select and ctrl-v.
> Using a shell is just painful for me in anything other than macOS for that reason alone.
On Linux at least you can use Ctrl-Shift-x, Ctrl-Shift-c and Ctrl-Shift-v for cut, copy and paste in the terminal. So again it's just a case of getting use to the shortcut differences.
On macOS Del can also be found on fn-Backspace and I often remap the right Alt key to Ctrl.
It's pretty easy to adapt to either with a little time.
> Will keyboard shortcuts be primarily using Control or Super?
On linux, Super as the shortcut for window operation is gaining ground, leaving Control and Alt for the other shortcuts.
Control is idea for the text shortcuts (emacs: Ctrl-A for beginning, E for end etc), and Alt for the menus (ex: Alt-F for files) even if there are a lot of crossovers (ex: Ctrl-F for find)
> this is almost entirely because of the conflict of Control-C in the terminal
I would suggest you remap intr to ^X : stty intr ^X : the X and C keys are very close, so it becomes natural very quickly
I've seen quite a few people doing it, it inspired me to do the same: it very quickly becomes natural, far more that Shift-Ctrl-C
> The default key bindings are intuitive. Input text as normal, use directional keys to move around, use Ctrl-S to save, Ctrl-O to open, Ctrl-X to exit.
Ctrl-X to exit is not intuitive. That's used to cut text almost everywhere. Instead, use Ctrl-Q (quit).
It's been 35 years since CUA[1]. Another terminal editor, micro[2], already adopted these conventions—Ctrl-C to copy, Ctrl-X to cut, Ctrl-V to paste—other terminal editors should as well.
> Some key mappings break in text boxes. I've remapped Find to Control+F, which works most of the time, but not if my cursor is in a text box, because then it moves the cursor forward. Control+B for bold and Control-A for select all are likewise. To make it worse, this only happens for certain text boxes, and heck if I can figure out the pattern.
Don't remap Cmd+<key> shortcuts to Ctrl+<key>. The great thing about the cmd key is that it doesn't conflict with anything else. Ctrl-f is forward, ctrl-b is back, ctrl-a is beginning of line, etc, these have been around in emacs (readline?) for a long time and it's great that native os textboxes implement them. This is why it's inconsistent; bad apps use their own snowflake controls and fail to implement them.
cmd-<key> don't conflict which is why they're used. Ctrl-c meaning both SIGINT and "copy to clipboard" is a disaster on terminals, the cmd-c life is much better. By trying to remap cmd to ctrl you're working against the OS and the OS will fight you back because it's not designed to do that.
> you’re stuck in this bizarre land where you have to ctrl+c and cmd+c for different tasks
Which I find quite reasonable, personally. If I want to copy text, it's Command-C everywhere in the system, even in the terminal–no Command-Shift-C or similar "hack". If I want to send a SIGINT to a program it's Control-C, as it should be.
> Nobody outside a minority of devs refers to Ctrl+c as C-c.
First, C-c is not Ctrl + c; second, it really helps to use compact notation when you read a lot of keybindings; and third, this is approximately the most minor complication in the learning curve of Emacs (otherwise nobody would learn vim, with its insane key mappings and invisible mode transitions).
> on Macs the CMD key is simply a poor man's CTRL key, except when you are in a terminal, where you have to use CTRL again...
Let me check.
Cmd-F in Notes.app, finds things in the current note.
Cmd-F in Terminal.app, finds things in the current terminal session's history.
Cmd-C in Calendar.app, copies an event.
Cmd-C in Terminal.app, copies the selected text.
Cmd-T in Finder.app, opens a tab.
Cmd-T in Terminal.app, opens a tab.
Cmd-W closes the current window/tab. Cmd-Q quits the app. Cmd-S saves. And so on, in any app, tracing back to 1984 or so.
Whereas Ctrl-C, Ctrl-T, Ctrl-F, Ctrl-S, on Windows/Linux... all do wildly different things, depending whether you are in an xterm, cmd.exe, a game, Emacs, or some other app.
You know what else? Ctrl-C in Terminal.app does the same thing as Ctrl-C in an xterm. This sort of thing is consistent in every app. You're literally having your cake and eating it too.
Windows couldn't use Ctrl-W to mean "close the current tab" in every single application, because - indeed, in a game, holding down Ctrl could mean crouch/sneak, and W to move forward. Windows could've chosen to use Win-W for that, but ignored the opportunity.
> anyway, this is just a coincidence
One of these patterns visible here is deliberate design, the other is piled up coincidences. I don't think it's that easy to confuse one for the other?
> It is not a good idea to use the backslash as the trigger key since it is the traditional line continuation and escape character on UNIX.
Well it is also the default key binding for VIM's leader key and placed on the home row on US keyboards which makes it really accessible.
What is not shown in the demo screencast is that leader detects whether the cursor is inside a quoted string and in that case doesn't present a menu but tells the shell to insert a literal backspace at the current cursor position.
For continuing lines on an interactive shell the user would have to press Ctrl+V followed by a backslash to insert a literal backslash. In my experience this is rarely necessary in an interactive terminal so the extra utility gained by having leader on the home row outweighs the extra key press necessary for continuing a line.
> Furthermore it is not a good idea to replace the command line with a menu since that limits what is possible in UNIX.
That is true. Leader is not _replacing_ the command line, the command line still works as usual, the only difference is that you can launch a menu by typing backslash to quickly run a command.
YMMV, but I've used both quite a bit and I find the shortcut in the article much more convenient than Ctrl-R, at least if I'm actually sure of the first characters of the command. They're not exclusive, anyway. :)
I rarely ever use Ctrl-r since I usually know the starting part of the command I want. So, I type those starting characters and use up/down arrow keys, courtesy these lines in `~/.inputrc`
reply