5 ms·

Nano default key bindings are not standard either. They are less different than vi from a typical GUI input controls and having a menu at the bottom of the scre

by _0w8t 4y ago

Nano default key bindings are not standard either. They are less different than vi from a typical GUI input controls and having a menu at the bottom of the screen help, but they force the user to get used to yet another convention. I was considering at some point to create a patch to nano to have a simple option to switch to more common bindings or even ask the user on the first run about it. But then I discovered the micro editor and simply have been using that.

Sebb767 4y ago
I'm pretty sure that's due to conflicts with default console bindings. That being said, always having a cheat sheet at the bottom makes this mostly a non-issue, even when using something easier as a baseline than vi.
virtualritz 4y ago
The thing is that the most imporant commands are shown at the bottom and just editing a file and the exiting will prompt for a save. This is good UX. No surprises, the most likely thing the user intended is the default and doesn't require any app-sepcific knowledge. I recall the very first time I was thrown into emacs because it was the default at university terminals (around 1993, I think). And I recall the first time I was thrown into nano (I think it was on Gentoo, maybe around 1999). The difference in UX couldn't have been more stark.
just_mc 4y ago
+1 for Micro
garciasn 4y ago
They're standard for beginning of line, end of line, cut line when using bash/zsh; that's already most of the way there. I use vim day to day but I do miss pico's ctrl-k/ctrl-u behavior for doing quick block cut/paste.
- minusf 4y ago
  most shells support both emacs shortcuts and vi style commands so there are at least 2 "standards" fwiw.
wankle 4y ago
I think that's why I've never shifted from vi to nano, it appears to be a regular editor but ignores all common key bindings, ctrls+s doesn't save, ctrl+f doesn't find, ctrl+h doesn't replace, etc.
- kazinator 4y ago
  I just fired up Nano on Ubuntu 18 installation. When I typed Ctrl-S, I was prompted for a file name. Nano saved the buffer into that file. I then made edits and used Ctrl-S again; it saved again without prompting. Furthermore, if nano is invoked with a filename argument, then Ctrl-S doesn't prompt. Ctrl-H is indistinguishable from ASCII backspace; if it does anything other than erase the character to the left of the cursor (possibly after climbing to the previous line, if the cursor is at the start of a line), it is objectively, positively wrong. You can distinguish Ctrl-H from backspace in a GUI system where you get detailed keyboard events. Nano has to work in a terminal.
  - wankle 4y ago
    You're right ctrl+s works, I tried it, I always thought it had to be ctrl+o since that's what the bottom panel shows. I was encouraged so I highlighted some text then tried ctlr+c and ctrl+v, unless I hit a wrong key somewhere, it didn't work.
    - kazinator 4y ago
      Ctrl-C and Ctrl-V are not common keybindings, unless we are talking about the Microsoft Windows environment, and graphical environments aped after it. In the GNU/Linux environment, the standard keybindings are the Emacs-derived ones. Ctrl-A to go to the start of the line, Ctrl-E to jump to the end, ... pasting is called "yank" and mapped to Ctrl-Y. Your point stands since GNU Nano doesn't stick to these either. Ctrl-C is interrupt in the TTY environment. This is so entrenched that programs which obtain Ctrl-C as ordinary input rather than a SIGINT signal still use it for interruption. E.g. in Vim, we can use Ctrl-C to interrupt long operations. Ctrl-V is entrenched as a "verbatim" key: insert the following character literally, even if it is a control character.

by _0w8t 4y ago

Sebb767 4y ago

I'm pretty sure that's due to conflicts with default console bindings. That being said, always having a cheat sheet at the bottom makes this mostly a non-issue, even when using something easier as a baseline than vi.

virtualritz 4y ago

The thing is that the most imporant commands are shown at the bottom and just editing a file and the exiting will prompt for a save. This is good UX. No surprises, the most likely thing the user intended is the default and doesn't require any app-sepcific knowledge. I recall the very first time I was thrown into emacs because it was the default at university terminals (around 1993, I think). And I recall the first time I was thrown into nano (I think it was on Gentoo, maybe around 1999). The difference in UX couldn't have been more stark.

just_mc 4y ago

+1 for Micro

garciasn 4y ago

They're standard for beginning of line, end of line, cut line when using bash/zsh; that's already most of the way there. I use vim day to day but I do miss pico's ctrl-k/ctrl-u behavior for doing quick block cut/paste.

minusf 4y ago
most shells support both emacs shortcuts and vi style commands so there are at least 2 "standards" fwiw.

wankle 4y ago

I think that's why I've never shifted from vi to nano, it appears to be a regular editor but ignores all common key bindings, ctrls+s doesn't save, ctrl+f doesn't find, ctrl+h doesn't replace, etc.

kazinator 4y ago
I just fired up Nano on Ubuntu 18 installation. When I typed Ctrl-S, I was prompted for a file name. Nano saved the buffer into that file. I then made edits and used Ctrl-S again; it saved again without prompting. Furthermore, if nano is invoked with a filename argument, then Ctrl-S doesn't prompt. Ctrl-H is indistinguishable from ASCII backspace; if it does anything other than erase the character to the left of the cursor (possibly after climbing to the previous line, if the cursor is at the start of a line), it is objectively, positively wrong. You can distinguish Ctrl-H from backspace in a GUI system where you get detailed keyboard events. Nano has to work in a terminal.
- wankle 4y ago
  You're right ctrl+s works, I tried it, I always thought it had to be ctrl+o since that's what the bottom panel shows. I was encouraged so I highlighted some text then tried ctlr+c and ctrl+v, unless I hit a wrong key somewhere, it didn't work.
  - kazinator 4y ago
    Ctrl-C and Ctrl-V are not common keybindings, unless we are talking about the Microsoft Windows environment, and graphical environments aped after it. In the GNU/Linux environment, the standard keybindings are the Emacs-derived ones. Ctrl-A to go to the start of the line, Ctrl-E to jump to the end, ... pasting is called "yank" and mapped to Ctrl-Y. Your point stands since GNU Nano doesn't stick to these either. Ctrl-C is interrupt in the TTY environment. This is so entrenched that programs which obtain Ctrl-C as ordinary input rather than a SIGINT signal still use it for interruption. E.g. in Vim, we can use Ctrl-C to interrupt long operations. Ctrl-V is entrenched as a "verbatim" key: insert the following character literally, even if it is a control character.