Hacker News new | ask | show | jobs
by z1mm32m4n 3378 days ago
In general, I think people really sell themselves short by using an editor "distribution." It's a "teach a man to fish" situation. The whole point of being able to configure Emacs or Vim is so that each person can make it into the tool he or she wants it to be.

That's sort of why I recommend Vim as an IDE[1] to people. It teaches people how to configure Vim for themselves, so they can better understand how the pieces come together.

[1]: https://github.com/jez/vim-as-an-ide

8 comments

This is also why I decided to use Keith Bostic's nvi [0], also known as vi from BSD. I got so tired of endless configuring and bikeshedding my own editor instead of getting work done.

Since I switched to nvi I've learned way more about the powerful features of the base editor as well as shell tools like grep, fzf, fmt, column, wc, expand, pdftotext, pandoc, make, git... With tmux I have easy access to any REPLs and man pages I need. The main feature of nvi I need over the original vi is unlimited undo, though ex command history and file name completion are nice as well.

Part of the inspiration for me to switch from vim (and spacemacs) down to nvi was this post on stack overflow [1]. When I really grokked the power of this system I picked up O'Reilly's book on vi and vim [2] and read every page of the vi and ex stuff. There is soooooo much you can do with this editor that doesn't require plugins yet people reinvent them, often in a less powerful/flexible way.

Since learning to be productive in nvi, it's going to be very hard to go back to those bigger, more extensible editors. The temptation for bikeshedding is too great... Oh, and learning to read code with syntax highlighting turned off is really nice. It helps you write more clearly since you aren't relying on the highlighting to help the reader.

[0] https://sites.google.com/a/bostic.com/keithbostic/vi/

[1] https://stackoverflow.com/questions/1218390/what-is-your-mos...

[2] https://shop.oreilly.com/product/mobile/9780596529833.do

As far as I remember you are foregoing text objects which are really one of the most powerful things in vim.

http://blog.carbonfive.com/2011/10/17/vim-text-objects-the-d...

Ironically I think most of the IDE (ie intellij etc) vim plugins have them while you do not.

Yeah, I'm aware of text objects (I used vim for years). I don't miss them as much as I thought I would. Most of them can be replaced by compositions of the primitive motion commands. Heck, you could probably even outright replace them with macros. I just haven't felt the need to.
TIL that there are text objects for tags. Thanks!
What programming languages do you use with nvi? Some seem awfully verbose without some kind of code completion.
Lately I've been writing a lot of LaTeX rather than programming. Nvi has macros, mappings, and abbreviations so it's not hard to deal with verbosity. In the past, I've written in languages like python, Haskell, SQL, R, and even HTML. It's never been a problem. I've never had to write Java though, so maybe I'd use something else if I were forced to.

Code completion, like syntax highlighting, seems to be one of those tools that changes how you think and I'm not sure it's for the better. Being able to quickly bang out a bunch of glue code may be great for a 9-5 but I think it gets in the way of the creative process. That's just my opinion, though. I'm not aware of any research into this idea.

I personally have never used code completion, though I don't think it's affected me much as a C, Python and Lisp programmer. I wouldn't want to try Java without an IDE, though (I use Emacs).
I've used "elvis" in the past as it has good syntax highlighting. I'm not seeing that as part of nvi's feature set.
I agree with this sentiment. Spacemacs is great, and if Spacevim is anything like it, it will be a great way to get a pretty full featured Vim editor.

However I've recently started from scratch with Vim 8.0 so that I could try out the new packaging features that are built in. I also wanted to be able to use the same configuration across Windows and Linux, which I'd found difficult with some package managers.

I've been pretty happy with the result so far. There are still some things that don't work correctly on Windows (shell incompatibilities in plugins mostly), but for the most part it's my IDE now.

One thing I will say for distributions is that it is a great source of new plugins that I haven't heard of or considered before.

https://github.com/deevus/dotfiles/blob/master/.vimrc

You miss a major benefit: the ecosystems of these editors evolve very quickly. Packages are updated and broken regularly, adding new features and interoporability that you may not be able to learn about yourself.

A community configuration like Spacemacs will continually update to provide you with a configuration that is up to date and doesn't break.

A community configuration like Spacemacs will continually update to provide you with a configuration that is up to date and doesn't break.

As far as I understand, it currently does not do that, since elpa/melpa/... packages are updated out of sync with Spacemacs and the last Spacemacs release is over 2 months old. See:

https://github.com/syl20bnr/spacemacs/issues/2057#issuecomme...

But, there is hope, the release notes for 0.200 say:

For 0.201 we plan to introduce stable snapshots of elpa repositories, a new installation of Spacemacs will always install packages from this stable source.

'Up to date' doesn't mean 'bleeding edge'; a two-month-old (or even year-old) distribution can be up-to-date.
This is a tradeoff not everyone can afford to make. A clean Spacemacs installation right now brings in a broken org-mode that cannot do exports. Spacemacs needs version pinning and stable package channels.
Vanilla vim is like compiling - efficient, but with a huge upfront investment. A vim 'distribution is like JITing - you end up at roughly the same spot, but it actually lets you do the thing in the meanwhile.
I think this only works if we allow that JITing is harder to understand and improve, because distributions tend to be opaque.
Logged in to say thanks for the link.

If I may suggest - have you considered adding it to the Awesome List either at:

https://github.com/sindresorhus/awesome OR https://github.com/mhinz/vim-galore ?

One of the reasons I like vim is that I can find vim or vi almost anywhere I need to work, but I try not to configure it too much (and lose out on what people say is one of the greatest advantages) BECAUSE I work on so many servers... is there a solution other than "carry your config and plugins everywhere?"
Tramp mode in Emacs is great for this, you can edit files over ssh seamlessly from your desktop. It works even better if you use Emacs as a terminal, as then you pretty much use tramp for everything.
Upload your vimrc file and .vim directory to github and just do a clone on every new server.
I used this approach, but the problem with it is that all the plugins should be synced in it, so the repository becomes larger and larger with time, or kept as submodules what adds additional friction. Also you should manually copy .vimrc to your home directory from the cloned repository.

So I put to the repository only .vimrc and an short shell script install.sh that installs Vundle, .vimrc, and then installs all the plugins by running "PluginInstall" command in vim. Installation becomes just cloning the repo and running install.sh from it.

The additional benefit in comparison to say putting plugins to git submodules is that I don't have to keep my vim repository at GitHub up-to-date with latest plugins versions because Vundle anyway installs the freshest versions.

My point, which I didn't state clearly, is that there are situations where this isn't really feasible; secured networks, servers not on the internet, etc.
I echo this sentiment. I was never able to truly get productive with vin until I started with a vanilla configuration and added features as I needed them. Once I did that it fit like a glove.
I think some people will find this to be the case, but others (me) are really happy using a distribution. I struggled for a while trying to get vanilla Emacs to the point where it felt natural and didn't bother me, but ultimately wasn't able to. I've been using Spacemacs now for over half a year with only a handful of customizations, and I've been very happy with it.