4 ms·

Nice, but still wondering if I should know vim since nano is enough for me :)

lucb1e 6y ago
Can you tell me how to exit nano without writing changes? Every time some silly default server kicks me into nano I'm absolutely lost and ctrl+c doesn't give you help text like in vim iirc. (Not kidding)
- calmoo 6y ago
  It's CTRL+X and then N to not save changes
  - lucb1e 6y ago
    Thanks! Gonna try to remember that combo.
    - Smaug123 6y ago
      It appears in the table of commands at the bottom of the screen by default, doesn't it?
      - lucb1e 6y ago
        I don't remember exactly, I just remember having a hard time exiting nano but not vim (also not before I knew vim: it just tells you what to do when you press the usual ctrl+c). From the sibling comment to yours, it says ^X which probably wasn't clear to me is supposed to be ctrl instead of shift. With hindsight it seems quite obvious, I'll admit.
    - mkl 6y ago
      You don't even need to remember it. At the bottom it lists keyboard shortcuts, and on the left is "^X Exit". When you press it with a modified file, it gives you: Save modified buffer? Y Yes N No ^C Cancel
yakshaving_jgt 6y ago
They aren't comparable.
thanato0s 6y ago
You should just try seriously. First because many CLI have vim-like keystrokes, second because when you're lost on a remote server or on a docker container without nano you can use vi (close enough), and third because it might change your life :D
scottlamb 6y ago
I recommend learning the basics. It's great being able to navigate around a file with the keyboard in ways other than arrow keys to move a line at a time. Stuff like hitting "%" to move between matching parenthesis, { and } to move between paragraphs, etc. And if you do any kind of development, the automatic indentation (and < and > to indent and outdent ranges) are hugely useful. All of these are also things you can use in IDEs like VS Code with their vim modes. The stuff in this article is pretty neat but (even after using vim for about 20 years) most of it doesn't click for me as easily. Eg I don't use marks; I wouldn't think ahead to leave a mark or remember afterward which letter I used for it. Kudos to people who can gain productivity by using this stuff, but I'd need something other than an explanation of what the commands do to be effective with it. I do at least try to use the quickfix stuff; that's a pretty big productivity boost over manually going to the right file and line to fix an error spotted by my compiler.
- dllthomas 6y ago
  > I do at least try to use the quickfix stuff; that's a pretty big productivity boost over manually going to the right file and line to fix an error spotted by my compiler. I've mapped cnext and cprev to tab and shift-tab, to make it easy to bounce through things. Also, in my shell I have defined alias cbuf='vim - -c cbuffer!' which lets me do things like "make | cbuf" or "git grep -n foo | cbuf", which is great. Tangentially, all of this plays well with some things I've built out for dealing with diffs (https://github.com/dlthomas/diff-kit https://github.com/dlthomas/diff-kit) - dklocs will turn a unified diff into location-prefixed changed lines, dkcov will find the intersection of a diff and a coverage report (very useful for answering the question "how did I break that test?"), either of which can be piped right into cbuf.
  - scottlamb 6y ago
    I like that mapping. Typing ":cnext" and ":cprev" is quite awkward. Next time I use vim's quickfix list I'll try tab + shift-tab. I've been using VS Code + its Vim plugin recently anyway because I wanted to try out rust-analyzer and couldn't get it to work well with vim. (iirc I tried both YouCompleteMe and coc.nvim. Despite the name, the latter on classic vim; I haven't tried neovim yet. I thought they were supposed to be async, but at least one of them made vim hang for a long time when opening a fresh project, which drove me nuts.) Neat idea also with the alias. Do you also have alias make='make 2>&1' or something? [edit: maybe make() { /path/to/make "$@" 2>&1 }] It doesn't work for me otherwise since compiler/make errors go to stderr (as they should).
Uhhrrr 6y ago
Even as a daily emacs user I got value out of learning vi a while ago. It's better for some kinds of editing and generally works better than the emacs bindings for job interview browser apps.
dehrmann 6y ago
I know the basics because vi ships with practically ever *nix (unlike Emacs), so it's there for when I need to edit config files, but I do 97% of my real work in something more like IntelliJ, so there just aren't big returns for getting better at vim.
- Smaug123 6y ago
  The Vi bindings in IntelliJ-based IDEs are pretty damn good in my experience. Certainly I feel a lot happier { and }'ing my way around, and having my `ce` and `gg` and `C`, in Rider.
- artificialLimbs 6y ago
  My professor takes an excrutiatingly long time to edit files in class using keyb + mouse in IntelliJ. I am frequently waiting on him to finish up because of the vim plugin for IntelliJ. The speed of editing with vim, once you learn it, is shocking.

Can you tell me how to exit nano without writing changes? Every time some silly default server kicks me into nano I'm absolutely lost and ctrl+c doesn't give you help text like in vim iirc. (Not kidding)

calmoo 6y ago
It's CTRL+X and then N to not save changes
- lucb1e 6y ago
  Thanks! Gonna try to remember that combo.
  - Smaug123 6y ago
    It appears in the table of commands at the bottom of the screen by default, doesn't it?
    - lucb1e 6y ago
      I don't remember exactly, I just remember having a hard time exiting nano but not vim (also not before I knew vim: it just tells you what to do when you press the usual ctrl+c). From the sibling comment to yours, it says ^X which probably wasn't clear to me is supposed to be ctrl instead of shift. With hindsight it seems quite obvious, I'll admit.
  - mkl 6y ago
    You don't even need to remember it. At the bottom it lists keyboard shortcuts, and on the left is "^X Exit". When you press it with a modified file, it gives you: Save modified buffer? Y Yes N No ^C Cancel

yakshaving_jgt 6y ago

They aren't comparable.

thanato0s 6y ago

You should just try seriously. First because many CLI have vim-like keystrokes, second because when you're lost on a remote server or on a docker container without nano you can use vi (close enough), and third because it might change your life :D

scottlamb 6y ago

I recommend learning the basics. It's great being able to navigate around a file with the keyboard in ways other than arrow keys to move a line at a time. Stuff like hitting "%" to move between matching parenthesis, { and } to move between paragraphs, etc. And if you do any kind of development, the automatic indentation (and < and > to indent and outdent ranges) are hugely useful. All of these are also things you can use in IDEs like VS Code with their vim modes. The stuff in this article is pretty neat but (even after using vim for about 20 years) most of it doesn't click for me as easily. Eg I don't use marks; I wouldn't think ahead to leave a mark or remember afterward which letter I used for it. Kudos to people who can gain productivity by using this stuff, but I'd need something other than an explanation of what the commands do to be effective with it. I do at least try to use the quickfix stuff; that's a pretty big productivity boost over manually going to the right file and line to fix an error spotted by my compiler.

dllthomas 6y ago
> I do at least try to use the quickfix stuff; that's a pretty big productivity boost over manually going to the right file and line to fix an error spotted by my compiler. I've mapped cnext and cprev to tab and shift-tab, to make it easy to bounce through things. Also, in my shell I have defined alias cbuf='vim - -c cbuffer!' which lets me do things like "make | cbuf" or "git grep -n foo | cbuf", which is great. Tangentially, all of this plays well with some things I've built out for dealing with diffs (https://github.com/dlthomas/diff-kit https://github.com/dlthomas/diff-kit) - dklocs will turn a unified diff into location-prefixed changed lines, dkcov will find the intersection of a diff and a coverage report (very useful for answering the question "how did I break that test?"), either of which can be piped right into cbuf.
- scottlamb 6y ago
  I like that mapping. Typing ":cnext" and ":cprev" is quite awkward. Next time I use vim's quickfix list I'll try tab + shift-tab. I've been using VS Code + its Vim plugin recently anyway because I wanted to try out rust-analyzer and couldn't get it to work well with vim. (iirc I tried both YouCompleteMe and coc.nvim. Despite the name, the latter on classic vim; I haven't tried neovim yet. I thought they were supposed to be async, but at least one of them made vim hang for a long time when opening a fresh project, which drove me nuts.) Neat idea also with the alias. Do you also have alias make='make 2>&1' or something? [edit: maybe make() { /path/to/make "$@" 2>&1 }] It doesn't work for me otherwise since compiler/make errors go to stderr (as they should).

Uhhrrr 6y ago

Even as a daily emacs user I got value out of learning vi a while ago. It's better for some kinds of editing and generally works better than the emacs bindings for job interview browser apps.

dehrmann 6y ago

I know the basics because vi ships with practically ever *nix (unlike Emacs), so it's there for when I need to edit config files, but I do 97% of my real work in something more like IntelliJ, so there just aren't big returns for getting better at vim.

Smaug123 6y ago
The Vi bindings in IntelliJ-based IDEs are pretty damn good in my experience. Certainly I feel a lot happier { and }'ing my way around, and having my `ce` and `gg` and `C`, in Rider.
artificialLimbs 6y ago
My professor takes an excrutiatingly long time to edit files in class using keyb + mouse in IntelliJ. I am frequently waiting on him to finish up because of the vim plugin for IntelliJ. The speed of editing with vim, once you learn it, is shocking.