Live data from Hacker News

Why Vi Rocks

why-vi.rocks

71–80 of 80 posts

Re: Why Vi Rocks

#71

Earlier quoted context omitted.

Unless I've misunderstood, you can use splits to show multiple buffers in Vim without any plugins.

What about manipulating of splits, like converting vertical split to a horizontal split, enabling/disabling synchronized scrolling, etc..

You can do both of those things in vim. I don't mean to be nitpicky, I'm just mentioning in case someone reading this didn't know and uses vim. You can set scrollbind and convert splits (off the top of my head I think it's Cw Ch and Cw Ct).

Re: Why Vi Rocks

#72

Earlier quoted context omitted.

Motion in Vi is based on treating the home row of the keyboard as arrow keys. H, J, K, and L are left, down, up, and right. They aren't mnemonics, and so scrambling them around (Dvorak) is just doubly confusing.

Oh, huh, never considered that a real issue. I've used Vim on Dvorak for years, and use hljk for motion. It's nice that jk are adjacent on Dvorak, and hl are conveniently placed as well.

Can confirm, I use Dvorak and vim without issues. I find myself not using hjkl very often though, since I can usually use another movement to get where I want to go, so it's really not an issue.

Re: Why Vi Rocks

#73
post #14

Vim is like Dvorak. The cognitive burden for remembering which key maps to what is high unless you use it 24/7.

Does anyone use Vim on a Dvorak keyboard?

I do, and it works well. I tend to use movements other than hjkl for moving around, so that doesn't bother me too much. I don't remap anything, and my config is pretty bare.

Re: Why Vi Rocks

#74

Earlier quoted context omitted.

Vim is a fantastic text editor, but it is not an IDE replacement. Here's just a few IntelliJ features I use daily that Vim doesn't have: Go to declaration, find usages, rename method/class, change method signature, auto-import, shortcut to override method, easy-to-configure style rules, really good code completion, quick access to javadoc. I could keep going. Again, not hating on Vim. I use Vim keybindings in Intelli…

Vim was designed for editing _text_. It was not designed for semantic analysis of _code_. The semantic plugins for Vim are hacky addons. Having Vim bindings in IntelliJ is indeed the best of both worlds.

How do you get IntelliJ to not shred your CPU to pieces while indexing all the time?

Re: Why Vi Rocks

#75

i see people struggling, fighting with Intelli-J every day. I wish I could give them vim as a gift. All the extra stuff you think you can't possibly give up you don't need. I'm a professional text file editor. Vim is like playing the piano. I guess what I'm saying is learn to play the piano for real, and don't spend your life in a piano-player-helper IDE thing.

Vim is a fantastic text editor, but it is not an IDE replacement. Here's just a few IntelliJ features I use daily that Vim doesn't have: Go to declaration, find usages, rename method/class, change method signature, auto-import, shortcut to override method, easy-to-configure style rules, really good code completion, quick access to javadoc. I could keep going. Again, not hating on Vim. I use Vim keybindings in Intelli…

this is _exactly_ my point. Take the plunge. Go IDE-less. Discover how you can play the piano and rename methods yourself with something called "typing" and auto-import is so much fun, it's like a game where I yank and paste the right import from another file. I know it sounds crazy. But at the end of the day I don't fight Intellij but just play music on my keyboard. Disclaimer I was avid eclipse java programmer for years and one day went to vim and never looked back.

Re: Why Vi Rocks

#76
post #23

Earlier quoted context omitted.

Same here neovim with session management and tmux with session management, with tmux russerect and tmux continuum. And with the language server integration in neovim, its a swiss army knife that works well with most modern languages and devops.

I've got resurrect and continuum installed and all they ever seem to do is load up an empty vim window that is rendered improperly. What is your setup?

mostly https://github.com/tmux-plugins/tmux-resurrect/blob/master/d....

Re: Why Vi Rocks

#77
post #67

Earlier quoted context omitted.

C++ and JavaScript. I've got about 60 plugins installed and a highly configured vimrc. Some of the important ones: w0rp/ale junegun/fzf junegun/fzf.vim majutsushi/tagbar scrooloose/nerdtree jistr/vim-nerdtree-tabs erahhal/nerdtree-ack tpope/vim-commentary joegesualdo/jsdoc.vim Raimondi/delimitMate tpope/vim-surround vim-scripts/AutoComplPop Shougo/deoplete.nvim carlitux/deoplete-ternjs marijnh/tern_for_vim Rip-Rip/cl…

That's a useful list, thanks for sharing. What would be useful is if there was just a distribution of Vim that just had everything included for a specific language. Or at least a base and then a way to discover and add more from within Vim.

There are plugins made for a language, but they are usually bloated, it's cleaner to compose smaller plugins to achieve the same outcome.

Usually vim configs are like toothbrushes, everyone uses a special one. Here's mine that includes dozens of plugins, some of them repeated from colordrops' list:

https://gitlab.com/somini/dotnvim

Re: Why Vi Rocks

#78

I’ve learned some vi, and emacs, Visual Studio, VS Code, XCode, IntelliJ, and Android Studio. All the examples listed are pretty uncommon or trivial in any of the other IDEs (aside from the regex part, which is cool, but I never want to be in a place where I have to regex my code...ever). 90% of the time I’m doing simple code maintenance, with an occasional refactoring. And I know devs that swear by vi...they are dev…

I am writing this from emacs experience (some if not all these features are in vi as well), there are features from emacs that make a real difference in writing programs especially: * Unlimited yanking from kill rings: ie pasting text from history of the clipboard.(This is one thing I have most difficulty with when switching from emacs to modern editors) * Macro recording and playback : recording an arbitrary set of…

All of these features are also in "graphical" editors, despite the claims. M$ had been doing it for decades.

I remember a friend of mine showing how easy it was to block select in vim. I waited 30 secs or so. I showed him the same in visual c++ (circa 2000s). We then had a "vim-off". eg. Find/replace/regex across a range of things -- using only the keyboard. The best I conceded was how the highlighting of results was probably superior... (sublime text, and vs code are as good as that now)

I know a lot of people here love vi (and Emacs), but personally, the only command I'm happy to learn is :q (and I presume negative karma for this comment will result) :D

I always install le for my terminal connections, and fall back to nano where needed. I've been meaning to write a console editor of my own that matches ye-o olde vc++ and visual studio...

I think there's something in the vi evangelism that I haven't quite grasped... otherwise I'm sure I'd have been using it for decades.

edit: not sure about the yank/ clipboard history... but that's part of the os in gui world.

Re: Why Vi Rocks

#79

Earlier quoted context omitted.

Vim was designed for editing _text_. It was not designed for semantic analysis of _code_. The semantic plugins for Vim are hacky addons. Having Vim bindings in IntelliJ is indeed the best of both worlds.

How do you get IntelliJ to not shred your CPU to pieces while indexing all the time?

It should not be indexing all the time. Only when you load a new project.

Re: Why Vi Rocks

#80

Earlier quoted context omitted.

In a refactoring IDE, you never risk overmatching or under-scoping. You just rename the syntactic object and it's renamed exactly where it needs to be, including possibly on the filesystem and in git.

Importantly, you don't get that safety in comments or strings. The nice thing about replacing via vim is that you can restrict it to a selected block which also gives you a type of safety. Particularly for the situation I used replacement today, an IDE couldn't make it better and doing it only on a range was helpful.

Fair enough. An IDE will generally present you with matching strings on a project level and let you select which ones to change. But if you know where to look, replace within selection seems useful. Apparently IntelliJ supports that, but I've never thought to use it.
Post reply on HN