4 ms·

It sounds like he never wanted vim to begin with. He wanted an IDE, which vim isn't. Vim is your editor and Unix is your IDE. Effective vim does not start with

It sounds like he never wanted vim to begin with. He wanted an IDE, which vim isn't. Vim is your editor and Unix is your IDE. Effective vim does not start with a lot of plugins IMO. If you expect more than an editor from vim, you have come to the wrong place.

cup-of-tea 9y ago
> Vim is your editor and Unix is your IDE. That's the first time I've ever heard anyone say that. It has instantly changed the way I think about vim and now I understand the "emacs is an OS" thing fully. Having said that I do happily use both Unix and emacs and think they both have their place.
- chongli 9y ago
  If you take this philosophy to its limit, you can derive a ton of productivity with just plain vi (or nvi) and Unix tools. I use neovim nowadays but I always feel the draw of the purity and temperance of plain vi.
tombert 9y ago
I think that's kind of elegant, and helps validate my preferred environment of `tmux` + `nvim`
saltcured 9y ago
That's funny because I think of emacs the same way... it is my editor and Unix is my IDE. The only "modes" I use in emacs are different syntax-highlighting and the occasional visual buffer-compare to unsnarl a particularly awful merge conflict. In spite of being a Lisp and Scheme programmer back in the day, I have never had an urge to extend emacs with anything. I think it simply has the right UX for me. It possibly goes all the way back to me using Wordstar on CP/M as a child, which had a similar buffer-focused UX with control keys to temporarily do some non-text entry. I also nearly always use emacs in X windows mode with multiple "frames" (separate X windows) opened into the same set of buffers and rely on the mouse-driven menus to find less frequent options and commands that I don't keep in my muscle memory. I can get by in non-X mode over SSH but feel crippled, much like I do when vim is the only option on a system. Then, I'll just get in and out quickly to make small changes, preferring to navigate around via the shell/grep/less etc. while I plan my attack on a file.
lev99 9y ago
I've been using vim for over 10 years. This is, imo, the happy path to being very productive in vim. 1. Learn basic movements and insert/normal mode 2. Learn advanced movements. When you want to insert some text learn the fastest way to move your cursor to that location in normal mode. Learn the different way move from normal mode to insert mode. 3. Learn find & replace commands. 4. Learn macros for repetitive tasks. 5. Learn when to use visual mode. 6. Improve .vimrc file. Remap keys to reduce keystrokes based on your personal workflow. 7. Learn about buffers.
- pacomerh 9y ago
  This seems about right, I would add that it helps a lot if you go to vimgolf and try some of the exercises people do. It will make you do things differently and expand your vim horizon.
kazinator 9y ago
Vim is enough of an IDE for C programming, certainly. With ctags and GNU id-utils (mkid, lid), you get great code browsing: instantly find where things are defined using tags, and where they are referenced with ID utils. I map the K command (normally used for man page lookup for the word under the cursor) to do a lid lookup and turn the results into a quicklist. The :grep command is also mapped to lid lookups via grepprg. lid uses a binary database file named ID which is generated using mkid. It instantaneously finds all occurrences of any identifier in a fairly large tree, like the Linux kernel. There is a code completion plugin for Vim so when you type foo.bar->, you see a popup with a list of structure members and such. Of course, there is the great syntax highlighting and auto-indentation which catch coding typos as you make them: IDE-like feature. Vim's :make turns compiler errors into a quickfix list so you can move between them and fix. I map :W so that it saves the buffer and runs :make.
kazinator 9y ago
My #1 Vim tip: Use ":set hidden" (Don't rely on ":help hidden" to actually explain it, though.) Here is why you want to use it: You edit "file-a" and make some changes. Then you flip to "file-b" using ":e fileb". Vim says you cannot; you have unsaved changes. Okay, so you ":w" and then flip. But then you return to "filea" and want to undo the earlier changes. Oops: lapsing into a dumb Vi from Unix, Vim says there aren't any changes to be undone. Vim throws away buffers by default when you switch out of them, unless "set :hidden" is turned on. Then it behaves like any other normal application with multiple buffers. The "filea" buffer will stick around and keep its undo history, marks and other state.

cup-of-tea 9y ago

> Vim is your editor and Unix is your IDE. That's the first time I've ever heard anyone say that. It has instantly changed the way I think about vim and now I understand the "emacs is an OS" thing fully. Having said that I do happily use both Unix and emacs and think they both have their place.

chongli 9y ago
If you take this philosophy to its limit, you can derive a ton of productivity with just plain vi (or nvi) and Unix tools. I use neovim nowadays but I always feel the draw of the purity and temperance of plain vi.

tombert 9y ago

I think that's kind of elegant, and helps validate my preferred environment of `tmux` + `nvim`

saltcured 9y ago

That's funny because I think of emacs the same way... it is my editor and Unix is my IDE. The only "modes" I use in emacs are different syntax-highlighting and the occasional visual buffer-compare to unsnarl a particularly awful merge conflict. In spite of being a Lisp and Scheme programmer back in the day, I have never had an urge to extend emacs with anything. I think it simply has the right UX for me. It possibly goes all the way back to me using Wordstar on CP/M as a child, which had a similar buffer-focused UX with control keys to temporarily do some non-text entry. I also nearly always use emacs in X windows mode with multiple "frames" (separate X windows) opened into the same set of buffers and rely on the mouse-driven menus to find less frequent options and commands that I don't keep in my muscle memory. I can get by in non-X mode over SSH but feel crippled, much like I do when vim is the only option on a system. Then, I'll just get in and out quickly to make small changes, preferring to navigate around via the shell/grep/less etc. while I plan my attack on a file.

lev99 9y ago

I've been using vim for over 10 years. This is, imo, the happy path to being very productive in vim. 1. Learn basic movements and insert/normal mode 2. Learn advanced movements. When you want to insert some text learn the fastest way to move your cursor to that location in normal mode. Learn the different way move from normal mode to insert mode. 3. Learn find & replace commands. 4. Learn macros for repetitive tasks. 5. Learn when to use visual mode. 6. Improve .vimrc file. Remap keys to reduce keystrokes based on your personal workflow. 7. Learn about buffers.

pacomerh 9y ago
This seems about right, I would add that it helps a lot if you go to vimgolf and try some of the exercises people do. It will make you do things differently and expand your vim horizon.

kazinator 9y ago

Vim is enough of an IDE for C programming, certainly. With ctags and GNU id-utils (mkid, lid), you get great code browsing: instantly find where things are defined using tags, and where they are referenced with ID utils. I map the K command (normally used for man page lookup for the word under the cursor) to do a lid lookup and turn the results into a quicklist. The :grep command is also mapped to lid lookups via grepprg. lid uses a binary database file named ID which is generated using mkid. It instantaneously finds all occurrences of any identifier in a fairly large tree, like the Linux kernel. There is a code completion plugin for Vim so when you type foo.bar->, you see a popup with a list of structure members and such. Of course, there is the great syntax highlighting and auto-indentation which catch coding typos as you make them: IDE-like feature. Vim's :make turns compiler errors into a quickfix list so you can move between them and fix. I map :W so that it saves the buffer and runs :make.

kazinator 9y ago

My #1 Vim tip: Use ":set hidden" (Don't rely on ":help hidden" to actually explain it, though.) Here is why you want to use it: You edit "file-a" and make some changes. Then you flip to "file-b" using ":e fileb". Vim says you cannot; you have unsaved changes. Okay, so you ":w" and then flip. But then you return to "filea" and want to undo the earlier changes. Oops: lapsing into a dumb Vi from Unix, Vim says there aren't any changes to be undone. Vim throws away buffers by default when you switch out of them, unless "set :hidden" is turned on. Then it behaves like any other normal application with multiple buffers. The "filea" buffer will stick around and keep its undo history, marks and other state.