HN Books @HNBooksMonth

> I’m finding myself doubting the amount of time I’m dedicating to configuring/practicing vim

If it's not fun, then it's probably not worth it. It really depends on what VIM can do to improve your current workflow. So, you may need to drop the VSCode mindset while you start using VIM.

> but now that I’m trying to navigate medium/large projects,

I actually have trouble navigating large projects in VSCode. The buffer, tab, window model that Vim uses makes more sense to me (but it's unique to VIM afaik, so it may be jarring at first). Combine that with a fuzzy finder[1] and it allows:

- rip-grep to search for files with text / file names

- Searching through currently currently opened buffers

Whenever I have to use VSCode (mainly for the live share feature, I find myself pretty lost with VSCode's tab based interface (I usually end up with like 20 tabs cluttering my workspace, and tabs are local to a split, which is jarring for me).

> the vim endgame looks like

It never _really_ ends. Some VIM features that I miss when I use another editor are:

- Really nice integration with terminal commands. One thing that I do very often is copy the name of the current file: `!echo % | xclip -sel clip` so I can use the filename as an argument in a terminal split (running tests for example)

- Filters (`:help !`) so I can pass parts of a file in to a program that accepts standard input. Example: `'<,'>!jq` to prettify bits of JSON.

- Global commands and macros. VSCode vim supports them, but I've noticed that they can run pretty slowly.

- The buffer, tab, window, model (probably the biggest one I miss when I start using VSCode)

For LSP support, I've tried to migrate to neovim's native LSP tools, but I still find COC to be a lot more intuitive. You should feel right at home with it since a lot of the plugins are similar to their VSCode counterpart.

If you'd like a really general and guided tour of VIM, I'd recommend picking up Practial Vim[2] It really helped me understand the workflow a bit more. Approaching VIM with the mindset of another editor wont give you all the benefits of using VIM. Though, if the workflow doesn't click, then that's not a big deal. You can always go back to VSCode.

[1] https://github.com/Shougo/denite.nvim (many people use Telescope: https://github.com/nvim-telescope/telescope.nvim) [2] https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...

⬐ WorldMaker

> Whenever I have to use VSCode (mainly for the live share feature, I find myself pretty lost with VSCode's tab based interface (I usually end up with like 20 tabs cluttering my workspace, and tabs are local to a split, which is jarring for me).

Yes, VSCode definitely has its own model similar to Vim's buffer/tab/window but that is somewhat unique to VSCode. There are some deep keyboard shortcuts that are similar, but quite different to Vim's, and I recall the VSCode Vim plugin tries its best to split the difference, somewhat.

Something I find very helpful with VSCode tab management in complex scenarios is the "Open Editors" pane. By default it is at the top of the Explorer panel. I think it defaults to minimized in fresh installs, though, but deep in the past it was the "only" tab management interface and a little bit more central to early VS Code workflows so some of us learned to rely on it early and others coming into VS Code fresh don't notice it at all. It's still one of the easiest places to do more complex tab and split management when the vertical tab bars are too cramped to be as useful as a horizontal list of opened tabs/splits.

⬐ pcvonz

Awesome! This will make my liveshare sessions so much more bearable. I also found a plugin[1] that enforces single editors per tabs.

[1]: https://marketplace.visualstudio.com/items?itemName=martybeg...

I honestly don't understand why people use VIM or Emacs. I'm much more productive just with notepad.

If you think lowest-common denominator stuff like Notepad equals productivity because it's easy and "discoverable", then I got nothing for you.

There's a reason why the subtitle of Drew Neil's book is "Edit Text at the Speed of Thought": https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...

Because when you're reasonably proficient with Vim, you think of what to do and with a few keystrokes, you've done it without the interruption of reaching for a mouse, selecting a menu command, etc. For many edits, in the time it takes to grab a mouse, orient where the pointer is on the screen and begin the process of selecting a GUI command, etc., you'd already be done using Vim and you're off to the next thing you want to do. Anyone who's been in the flow of coding doesn't want something that interrupts that and Vim is great at keeping you there.

And because Vim uses a language, it's composable in way that VS Code, Notepad, Emacs and all of the rest of editors aren't. Once you understand how to delete a word (`dw` in Normal mode), you also know how to delete sentences, paragraphs, etc. Plugins can add their own text objects to extend the usefulness of the language.

More at "Why Vim Can't Replace Emacs/Sublime Text, etc.": https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385...

Forget about vim and emacs, those were for times when people were coding over SSH. Apparently you're not a systems admin, web developer or in devops, where people have to connect to servers via SSH and edit configuration files, scripts, etc. pretty much every day.

The beauty is you can use Vim on your desktop or laptop for local editing tasks (especially gVim) and for remote editing via SSH, FTP, rsync.

Finally, I've used over a dozen different editors over the years on macOS and other platforms; I decided I wanted one editor that had enough headroom that I couldn't outgrow regardless of the task at hand.

Even though I've been using Vim for 4 or 5 years as my primary editor, I've barely scratched the surface of what it enables me to do.

⬐ jokoon

Sublime Text is, to me, much more modern and useful than vim.

⬐ alwillis

Did you not read https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385..., which applies to Sublime Text as well?

I've used Sublime Text; it's not a bad editor; but compared to using Vim, it’s like being in quicksand.

Sublime Text should be more modern and useful than Vim, an editor with roots going back to the 1970's. As the article describes:

>Vi is fundamentally built on command composability. It favors small, general-purpose commands that can be combined with objects to compose larger commands. By contrast, Emacs and its philosophical descendants (including Sublime Text and Atom) use monolithic, special-purpose commands.

You can't add enough special purpose commands to something like Sublime Text and have it be useable to approach what one can do with Vi/Vim and its composability.

Finally, Vim 8.0 was released just last year (2016), so it's not like it's not being updated with new features.

Last thing from the aforementioned article:

>A new, shiny, modern editor could one-up Vim by fixing some (or hopefully all) of these issues. But before an editor can replace Vim, it needs to learn everything that 1976 has to teach — not just the lesson of Emacs, but also the lesson of vi.

This post has some valuable tips (I'm probably going to try out <Space> as a leader), but one or two near the start rub me the wrong way in terms of how I use vim and how it's my impression that it's intended to be used.

>It seems like vvv is slower than vp but in practice I don’t need to think beforehand what to select, and what key combination to use.

The way I've always used vim and always thought it was intended to be used is that you do think beforehand. You sit at your editor, think about what changes you want to make, and then key in a set of precision commands in vim-editing-language and it happens.

>This way v replaces viw, vaw, vi", va", vi(, va(, vi[, va[, vi{, va{, vip, vap, vit, vat, ... you get the idea.

I kind of like the precision of having all of those different things, and of course the option of using them for more than just visual select but also change, delete, and so on. Although I suppose this doesn't remove any of those keymappings, I must protest remapping Ctrl+v: I can't even use an editor without block select.

I imagine there's a plugin (or even builtin feature) that at least generalises "s, (s , [s, tags and things of that sort though.

>Stop that stupid window from popping up: >map q: :q

I know it's a weird and irritating thing to have that window pop up when you meant to quit, but it's actually a very neat interface: a whole vim buffer for recomposing commands and your command history for later execution (almost acme-like). Give the poor guy a chance.

As a counterpoint to what I've pointed out above, I'd like to recommend Drew Neil's [Practical Vim](http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...) to anyone who hasn't read it already. It's got a lot of great content, and really goes a long way to explain vim's quirks and methods of doing things.

One of the useful tips I learnt from that was the ex command "normal", which allows you to execute a string of normal mode commands over a range of lines. So, for example, you can append a semicolon to each line in a visual selection by entering

    :'<,'>%normal A;

A small thing, but one that I've used a lot since learning about it.

⬐ kweinber

+100 for Practical Vim... Hands down the best vim guide. After 10 years of kinda-knowing-vim, that book changed how I use vim entirely.

I haven't read it myself, but Practical Vim is quite highly regarded:

http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...

A whole book of tips

⬐ chongli

That sounds like a good book for a vim user. I wonder how much of it would apply to vi, however.

I'd like to second this. There is a lot to Vim and Practical Vim is an excellent read. This book covers a lot of ground and the way it internally references itself is excellent (great for jumping around).

Links for the lazy (non-affiliate)

http://pragprog.com/book/dnvim/practical-vim

http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...

The better you get at Vim the easier it is to learn more Vim.

⬐ keithpeter

For those outside the US who would like the paper version, use your local Amazon if possible. Postage is as much as the book from Pragmatic Programmer's site.