Its a historical artifact of how in-line edit emerged as a thing for most people. MIT had huge influence in the development of window systems (X10/X11) and adopted emacs string edit mode in most type in boxes. Bash came from a community which had a strong emacs usage. So, the default in both the window system and in the bash shell, was emacs, even if you use ed/ex/vi

Because most people used awk/grep/sed/ed/ex/vi the regex format tended that way. But enough people used tcsh or bash in emacs by default, that shell and omnibox (when browsers eventuated) edit defaulted to emacs.

Thats my theory: accidental happenstance and defaults.

And if I'm not mistaken, during that time, the ctrl key was typically where caps lock is today (maybe just on certain machines?) - and that is what influenced the frequent use of ctrl for key shortcuts in libraries lile readline.

Close:

https://en.wikipedia.org/wiki/Space-cadet_keyboard#/media/Fi...

may well be. not that escape is so far away from a pinkie, for the modal people (like me)

It pretty far away, compared to capslock. Especially on modern laptops.. lile touch bar macs that actually remove the the entirely

Hateful. Annoying. Thank goodness for kbd remapping

I am a fan of vi/vim, esp. as a remote shell editor. But the vi support in readline CLIs is overkill IMHO. I don't see the need for the 'extra power' of vi there, esp. the modes. A few well known keyboard short cuts are just fine for a CLI.

This also works the other way around: A few EMACS based shortcuts are the better 'lowest common denominator' than to force vi modes on everyone. Many are not willing to go down the vi/vim path, for various reasons.

I disagree, and find the vi mode (and extended Vim bindings) very useful in the shell.

Consider a long cURL command split over several lines. If every option is on a separate line, removing one is a `dd` keystroke away. Adding a new option is also very efficient.

Extended Vim bindings will also allow you to delete everything within brackets/delimiters (e.g. `di"`) or delete everything up until a character, etc. These are all simple keystrokes that translate well to the shell.

You could also open the command in your $EDITOR anyway (bound to `V` for me), but I reserve that for really long and unwieldy commands.

HOW DO YOU EXIT THIS SHELL??

ed(1) is the standard editor

https://twitter.com/ed1conf

After years of using Vim and Bash this was a relief that I learned way too late. For the lazy ones

  $ cat >~/.inputrc 
  set editing-mode vi
  set keymap vi

  $if mode=vi
    set keymap vi-insert
    "jj": vi-movement-mode
  $endif

Obviously you want to change vi-movement-mode to your favorite ESC style. E.g. searching through your last git commands becomes 'jj/git' then (you have to go to movement mode first, as insert mode is the default in the shell - which makes kind of sense).

Thank you for this! I had no idea this existed. It is perfect for vim users. Very happy that I can now jump around to my heart's content without learning a new set of keyboard shortcuts.

Even better is to create a .inputrc configuration file. This is used by readline so it will affect your shell and some other utilities. You can do even more in there too.

For example I use this:

  set editing-mode vi

  # Up and down arrows keys search history based on what is already typed.
  "\e[A": history-search-backward
  "\e[B": history-search-forward

This is actually my preferred config. The reason being emacs shell buffers. I can interact with any shell tool using the full text editing features of emacs. I've had to interact with many Oracle databases via sqlplus. "sqlplus" is not a fun tool to use on the shell. However in emacs it is perfectly fine and works as well as the command line interfaces from PostGRE or MySQL. The inline shell also allows automatic history, block selecting and line truncate/wrapping controls across all tools. However for pure text editing, it's always vim for me. I've even found myself launching emacs+shell within tmux in one pane and vim in another.

Sorry, unrelated nitpick but the name is PostgreSQL or Postgres. Postgres started in 1986 as a followup to Ingres and the name was meant to mean after-Ingres. The query language was later replaced with SQL and the name changed again to a portmanteau of Postgres SQL

It's never PostGRE.

https://www.postgresql.org/about/history/

Have you tried sqlcl from Oracle? 20 meg download (requires java). Up down left right work. Use sql hr@ instead of sqlplus hr @ (I am one of the developers.) . I should try it from within Emacs.

    emacs

Why not just use emacs everywhere? I suppose if you use spacemacs (which has vim keybindings) then you might want to 'set -o vi' on the command line.

Emacs has Org-mode & Magit, each of which should be reason enough to switch. Then there're notmuch, gnus, slack-mode, eww …

Seriously, emacs really is a more powerful environment[0]. Modern vim tries to be as flexible as emacs, but the language isn't as nice.

E.g. Damian Conway's[1] simple example:

    function! ToggleSyntax()
       if exists("g:syntax_on")
          syntax off
       else
          syntax enable
       endif
    endfunction
    
    nmap <silent>  ;s  :call ToggleSyntax()<CR>

would be:

    (defun toggle-syntax ()
      (syntax (not syntax))
    
    (global-set-key (kbd "M-C-s") toggle-syntax)

in a hypothetical elisp for a vim-like editor[2]. In his article he refers to vimscript a more humane than elisp, but I think this simple example shows he's wrong.

His next example is a command to capitalise a line, centre it, then move down:

    function! CapitalizeCenterAndMoveDown()
       s/\<./\u&/g   "Built-in substitution capitalizes each word
       center        "Built-in center command centers entire line
       +1            "Built-in relative motion (+1 line down)
    endfunction
    
    nmap <silent>  \C  :call CapitalizeCenterAndMoveDown()<CR>

I think this is a lot clearer:

    (defun capitalize-centre-and-move-down ()
      (interactive)
      (upcase-region (line-beginning-position) (line-end-position))
      (center-region (line-beginning-position) (line-end-position))
      (forward-line))

[0] https://sites.google.com/site/steveyegge2/effective-emacs

[1] https://www.ibm.com/developerworks/library/l-vim-script-1/in...

[2] For the real emacs, it's just font-lock-mode.

I've used Emacs off and on for years now. But I can never get to that place where I get totally emersed because of the clunky terminal/shell story. I've tried eshell but what always gets me is having to C-c while in the terminal or eshell to get back to a different buffer.

I prefer M-x and fuzzy function entry to key bindings and when I'm in a terminal buffer or eshell I always go for M-x which won't work.

Any tips would be appreciated as I really like everything else about Emacs.

term and ansi-term bind the whole keyboard, but eshell and shell don't. Are you sure you are really running eshell?

I used to have a command “vi” in eshell that basically ran find-file. It took some getting used to using Emacs keys after invoking a command vi, but it worked.

If you modify your .inputrc with the following this should propagate to all of readline as well (e.g. python):

    set editing-mode vi

What shell does that work in? On a mac, I have that set in my .inputrc and it does not propagate to python.

Bash. Actually it depends if the program uses libreadline - which should be the case for Python's REPL?

You may try `rlwrap` which wraps programs without readline support.

I came here to post that, glad you beat me to it. Reaching for that control key? Ouch. Though I guess when you use vi keybindings, you are occasionally reaching for the escape key.

But, there is something to be said for meeting people where they are. If folks know the emacs keybindings, let them 'control' away!

Remap that caps lock key that you never use to ctrl. Your life is changed. You are welcome :)

As a dyed in the wool Vi user. I still want ctrl where I can reach it easily.

Ctrl-[ for escape and when in Insert mode, ctrl-h backspace; ctrl-w delete word; ctrl-u delete line; Ctrl-m return; ctrl-i tab, etc.

I once swapped Ctrl and Alt and never looked back. It feels so natural and it happens to match Symbolics Space-Cadet Keyboards layout too http://xahlee.info/kbd/space-cadet_keyboard.html

Advised by http://xahlee.info/kbd/linux_swap_modifier_keys.html

    ! -*- coding: utf-8 -*-
    ! 2013-02-04 swap Alt and Ctrl http://xahlee.info/

    !  xmodmap -pke | egrep '(Control|Super|Alt|Menu)'
    ! keycode  37 = Control_L NoSymbol Control_L
    ! keycode  64 = Alt_L Meta_L Alt_L Meta_L
    ! keycode 105 = Control_R NoSymbol Control_R
    ! keycode 108 = Alt_R Meta_R Alt_R Meta_R
    ! keycode 133 = Super_L NoSymbol Super_L
    ! keycode 134 = Super_R NoSymbol Super_R
    ! keycode 135 = Menu NoSymbol Menu
    ! keycode 147 = XF86MenuKB NoSymbol XF86MenuKB
    ! keycode 204 = NoSymbol Alt_L NoSymbol Alt_L
    ! keycode 206 = NoSymbol Super_L NoSymbol Super_L

    clear control
    clear mod1
    keycode 37 = Alt_L Meta_L
    keycode 105 = Alt_R Meta_R
    keycode 64 = Control_L
    keycode 108 = Control_R
    add control = Control_L Control_R
    add mod1 = Alt_L Meta_L

Im a broken record in this thread right now... for goodness sake, remap capslock to ctrl!!

That's the first thing I do when I start a new MBP.

Yep, me too. The second thing I do is to remap the right alt key (used to be a numeric keypad 'enter' key back on my original MacBook Pro) to a second ctrl key.

I'm always confused by laptop designers who only include one ctrl key. How are we supposed to properly touch type modifiers otherwise?

> I'm always confused ...

Just stating the obvious: you’re not their target consumer.

Maybe, there's probably some truth to that.

Apple do make it easy to remap the Alt key though and include a terminal and CLI commands by default so they must have some interest in business from people like me. ;)

(I would like to start a campaign to get the Mac Unix science page back again https://www.macobserver.com/tmo/article/apple-drops-science-...)

different strokes for different folks. I did not know about those insert mode keystrokes. Thanks!

Yeah, I have some problems with RSI in my right wrist (stop sniggering at the back).

I think it's mostly down to the way I twist to reach backspace rather than move my whole hand from the home row. Ctrl-h, Ctrl-w and Ctrl-m really help with that.

The only problem I have is that I don't know how to remap Ctr-m to return in X windows applications. I use Karabiner on a macOS and Gnome Tweak tool on Linux for the others.

It's somewhat frustrating to have different shortcuts in the terminal, where I spend most of my time and the browser where I spend most of the rest.

Edit: (If anyone can suggest a good way of mapping ctrl-m to return in Linux browsers I'd really appreciate it.)

Also ctrl-c does everything esc does in vim. When capslock is remapped to ctrl, its far easier and faster in most cases than reaching for esc.

Doesn't ctrl-c clear the whole line (maybe SIGINT related?) in vi-mode?

Well, in vanilla vi - I'm not sure (quite frankly, anyone who stands by vanilla vi as a great way to edit text is fudging insane). In typical VIM installs, ctrl-c and esc are aliases of one another.

Yeah, I meant vi(m)-mode in Bash/readline as mentioned in this discussion. When editing or correcting a command it may be inconvenient to destroy the whole line when switching to movement-mode (which does not happen, if it is not ctrl-c).

On the Japanese keyboard, Ctrl is where it should be: above Shift, replacing the useless and memetastic CapsLock.

You can always use ctrl-[ instead of esc.

One thing that annoys me on macOS is that "set -o vi" stops tab completion from working when logging in as root.

  $ sudo -i
  $ cd /va<tab> #results in "cd /var"
  $ set -o vi
  $ cd /va<tab> #results in: "cd /va    "

Not enough people know about this config, bash/zsh compatible.