Hacker News new | past | comments | ask | show | jobs | submit login
Bram Moolenaar Discusses Developing Vim, How He Uses It, and Version 8 (hostingadvice.com)
234 points by laktak on Dec 22, 2016 | hide | past | favorite | 115 comments



I love vim, and I'm always happy to read interviews with the developers who make and manage the tools I use or like. However, I find this article to be somewhat of a mishmash with an uncertain audience. From the title, I had expected this to be a transcript of an interview. But it's not. Thank you for the link.

The article also heavily implies that Bram is the sole and only developer, and mentions that vim has had four updates since 2006. Both of these are true only up to extremely narrow interpretation, and not what I would expect from an article purporting to interview and describe a project maintainer and the project.


It's also on a scammy review site for hosting affiliate links, and fake crappy "ratings"


Has Bram Moolenaar ever publicly acknowledged the influence of Neovim on Vim 8? At the very least, Neovim provided the market research to show that async was worth doing.


I've not seen anything which is disappointing, the NeoVim team have done a fantastic job at modernising Vim. I've not followed Vim development very closely but the whole async thing did give me a chuckle when I read about it after years of not accepting async patches. A real shame he made it incompatible with the NeoVim async with no real reason.


Neovim is Vim for me and many other users. Vim is irrelevant to me now. The community is rallying behind Neovim and it shows great potential. It just needs to be bundled by major distros so it can be installed on servers with 1 command and that'll be the end of old Vim. Bram has done a tremendous job with Vim but it's time to move on to the Vim of the future.


Speaking solely as an outsider to the development of Vim, NeoVim, and Vim extensions - the only time I see references to NeoVim anymore is when someone else brings up regular Vim (and always includes the narrow-sighted rant of "vim is obsolete, neovim is the future").

Threads here imply that NeoVim has a lot more traction and capabilities than Vim, yet it might as well not exist for all that we don't hear about it.

> that'll be the end of old Vim

To be frank, no, it won't. Not so long as Vim is installed by default, and holds the name Vim. NeoVim can't even simply replace Vim as the default, since it works differently (the changed configuration path, for one), and no longer works on all of the platforms that operating systems are installed upon (even if intentionally).

Vim just works. Until that is no longer the case, NeoVim will have a hard time gaining traction outside of those who are already waving its flag.

That said, I appreciate NeoVim - if for nothing else - for prompting Bram to realize there are more usecases. But I would argue that its time has passed, as bright as that time was.


Neovim is objectively better in numerous ways. I don't need to list them here because a Google search should suffice.

It should be said that people who use Neovim often use the word Vim to keep it understandable and not seem annoying.


> Not so long as Vim is installed by default, and holds the name Vim. NeoVim can't even simply replace Vim as the default, since it works differently

Something about this comment (perhaps the above quote) makes me think that perhaps neovim will be to vim, what vim is to vi...


Vim never needed async, it Just Wo ESC j j j j jjj ESC rks(TM):q :wq


Why would it be the end of old vim? I've never used neovim and I don't plan to use it, vim is perfectly fine for me, as it is. I guess, most of vim users don't even know of neovim. Sure, it's good to have a choice.


A lot of other comments make related points that kind of dance around this, but here it is: The major improvements of neovim aren't (directly) user facing. It's a major refactor, which makes it immensely easier to maintain and contribute too. Neovim isn't a vim reinvention, it's a vim renewal.


What I think is interesting here is that Neovim is entirely contrary to the original point of Vim, as presented in the article: a vi available on non-Unix systems. It was portable, so it could be run anywhere. Now Neovim's selling point is that it DOESN'T have all the code that enabled that portability.

Not suggesting one way is better or worse, but I think it's interesting.


For me the major improvement is that it puts the settings in the .config folder. I like this because I keep my settings in a git repo.

The main advantage on the other hand is that my friend stopped bothering me about having to switch to neovim, which I guess is a non-issue for most. Now he's trying to get me on to zsh.


I've kept pretty much all my settings in a git repository for years -- you don't need the program to explicitly make that easier.

    $ git clone <<repository_url>> $HOME/config
    $ ln -sf $HOME/config/vim/vimrc $HOME/.vimrc


It's not the end of vim. I highly doubt NeoVim is going to replace it at all.


I've never touched neovim as I'm perfectly happy with vim - what reasons are there for me to consider making the switch?

I would guess neovim isn't even on the radar of most vim users. I don't see neovim surpassing vim any time soon, personally.


The honest truth is that almost everyone will have the same exact experience in neovim as in vim, and that the differences right now (this could always change) are mostly for developers hoping to use vim in a creative way. For example, nvim has a decoupled back end, so ides could emulate vim without having to do emulation at all -- they would literally just communicate with the neovim backend. Another example, which I think is great, is that to support python extensions, nvim does not need to be recompiled. A third one, which is perhaps the least valuable but is also the most user-facing, is that you can now open terminals within neovim. Of course, you can do this with vim and tmux, but sometimes it's nice that I can set up a binding for <leader>-t to open a terminal, or <leader>-p to open an ipython shell instead of using tmux's more cumbersome default bindings. That said, there are of course ways to set up fantastic tmux bindings, I just haven't.

I love neovim, but the idea that "most people use nvim" or "vim is dying" is just wrong. Though I really do think nvim's development philosophy will lead to better results than Moolenaar's.


What's really useful about the inbuilt terminal is that it's hooked up to the job control bits, which lets you do things like feed chunks of text to whatever happens to be running in it. I've got this set up as an operator[0] (fair warning, it's been a while since I've tested this much, and there are a few things it could probably do better), which is handy for, as an example, running python/irb/whatever in the terminal and sending function definitions to it as you write them.

EDIT: For the sake of being equal-opportunity, you can do the same thing in emacs with make-comint, even down to having it as an operator if you're using evil-mode. Y'know, whatever you're into.

[0]: https://gist.github.com/Wibjarm/5ae4c4da57bd034d15123cd8edad...


Neovim's popularity is more with extension developers. My understanding is that it enables them to develop features rivaling those in IDEs. Vim users won't switch for Neovim itself, but they might if extension writers only target Neovim.

I think Neovim also has a pluggable engine, so IDE vim emulators can simply include that portion rather than implementing the functionality per platform.


This was true for a while, but vim 8 (and some of the last patches of vim 7) added async tasks, channels and built-in JSON encoding/decoding. It's a hassle to have to support two different interfaces, but I suspect most plugin authors are going to do that rather than force their users to use neovim. Some plugins (like neomake) already support both.

Edit: Forgot to mention, many of the improvements in vim 8 were clearly in reaction to Neovim's innovations. Both projects benefit from the other, this isn't a fight to the death.


Can you name a couple of extensions that somebody considering Neovim should look at?


neomake (async execution of tasks like compiling, linting and syntax checking) and deoplete (for async autocompletion).


Neovim's async already has tremendous plugin support and is most obviously felt in new build plugins like neomake that do async linting--no more locking up the interface on saving, and this already works well.

Neovim's embedded terminal also works great and is something vim doesn't have.

Neovim is simple to try out because it's a drop-in replacement--all your old plugins will likely work out of the box, along with your .vimrc.


> what reasons are there for me to consider making the switch?

There are numerous improvements and features but I'll not talk about them. It has the momentum. Hundreds of developers are contributing to it. That should be the biggest reason to switch as it directly means Neovim will be much healthier than Vim which lacks the momentum.

If you want to know more about what exactly Neovim is doing on the technical side, I suggest you read up the 7 newsletters [0] since the inception of Neovim.

[0] https://neovim.io/news/


Features might be a compelling reason to switch. The fact that something is furiously developed by hundreds of developers is a very poor reason. What does this rather meaningless "health" of Neovim gives to the end users? Fresh new bugs?

I'm not arguing that there are no good reasons to try Neovim. I just don't see any logic in your argument. You speak about loosely defined "health" and "momentum" as if there was a clear link between software quality and amount of buzz around the project.


> The fact that something is furiously developed by hundreds of developers is a very poor reason. What does this rather meaningless "health" of Neovim gives to the end users? Fresh new bugs?

It's not like Neovim (or any open source project) is an open house where anyone can come, throw some code over the wall and get it merged. Like any big project (Vim included), it is being maintained by a set of core responsible developers who know better. Neovim has a huge focus on automated tests and CI also. I don't see any reason why a big contributor base should make the end product worse.

> I just don't see any logic in your argument. You speak about loosely defined "health" and "momentum" as if there was a clear link between software quality and amount of buzz around the project.

Of course there is. Look at Linux, ReactJS, Docker, Kubernetes, Ubuntu, Firefox. The more momentum a project has, the more contributions it gets. Open source projects succeed because of the community around them.

GNU Hurd was not able to gather momentum and look where it is today. Contributors flocked to Linux so it flourished.


> The more momentum a project has, the more contributions it gets

that's not disputed. the question is, what specific impacts do these contributions have on me, the user? why should i, a user of vim, switch to neovim?


async plugins? true color support? If you have a 32-bit color capable terminal you can use any colorscheme and get real RGB colors.


Those are very good and appealing features. Nobody questions that. On the contrary, the point is that those features are meaningful and valuable for the users. The amount of code and people used to implement them is not.


That got me: https://github.com/neovim/neovim/wiki/FAQ#how-can-i-change-t...

It feels faster to me, but I haven't compared to vim 8. I don't use any plugins doing work in the background, so that's not the difference here.


you can do that in vim as well http://pastebin.com/LLm0tx88


TBF that is non standard behavior and won't work everywhere.


That's interesting! I guess, neovim's behavior is just a convenience wrapper around this, then.


You must be living in a bubble tbh. I am using vim for 12+ years now and it is perfectly fine.


Vim is fine but Neovim is better and judging from the community involvement, will keep getting better at a much faster rate than Vim.


Vim is stagnant (or was?) which is fine for most users but sucks in the long run.

Would vim 8 have async if neovim did not exist? No, because it was fine without it.


From a Windows user point of view neovim is strictly than vim 8 / gvim 8.


Can't edit now but that was meant to be "strictly worse"


Yes, this. My primary work environment is Windows. Every attempt to install and successfully use neovim has been far from optimal and sometimes flat out broken. So I go back to gVim.


vim is great, but neovim is better. Of course these days I'm a spacemacs proselyte. On my dev box spacemacs and neovim is used interchangeably. On most servers I just stick with the default distro vim, unless it becomes a remote dev machine.

Point is I use all three all the time, and I fully expect to continue doing that until world hunger or me ends.


Plus 1 for spacemacs. Magit is amazing software and I held out for a long time learning it because I didn't think that it was worth the time. It's so good that it makes you rethink version control. Makes everything so easy... Even the more advanced features.



At 50:15, 54:00 and 59:10 [edit: also 1:05:15]. The last two are specif about the fork (all quite short).


Ah, 54:00 is what I was looking for. Thanks.


Good point. A recent upvoted post From Reddit's Vim sub [1]:

"I am super surprised that everybody talks about Vim 8 but almost nobody mentions that...

- Bram Moolenaar did the last major version ten years ago

- The recent years of Vim's development were almost stalling

- Bram publicly questioned the Neovim team's efforts creating a fork and bringing new essential stuff like async to Vim—he even made kind of fun of them

After Neovim came out and has been developed at fast pace, Bram surprisingly presents Vim 8 with the stuff we wanted which before he decided against—all the stuff Neovim did and of course incompatible to the fork.

Bram's decision on being incompatible should be challenged and discussed, would love to hear his thoughts. Since no money is involved, his decision feels even more awkward, why not welcome competition or potential contributors, being a team player, work together or merge? Or is it Bram's injured pride, the fear of getting irrelevant with some piece of ancient software?

Whatever 'meaningful reasons' Bram chose not to support a fork, now we are left with incompatible Vim variants which damage the entire Vim ecosystem. I guess that most distributions will package Vim 8 with their distributions, just because not everybody has followed all the happenings, and Vim 8 sounds like a solid choice, like going with the mainstream. So, Vim 8 might get the next standard and an awesome fork could die which I find sad. The Neovim team has been disrupting, they went ahead and it's a community developed software which is a huge differentiator to Bram's work and codebase of controversial quality.

What are your thoughts? Should we support both versions and should we write plugins for both or focus on one? Or is competition good and the Neovim team will deliver more and prove that still a community developed Neovim will outperform Vim in the long run?

Don't get me wrong, this isn't a rant, Bram created with Vim an fantastic piece of software—this is about the question how we should keep competition which helps the entire ecosystem so we don't end up with a dying fork and original Vim's development slowing down again for the next ten years. One idea is that all distributions should either still package old Vim 7.x only to let people decide themselves or always package both Vim 8 and Neovim together. But how should we get there?"

[1] https://www.reddit.com/r/vim/comments/52q4ul/about_vim_8_and...


I think that so long as the primary rhetoric from the NeoVim camp is "vim is dead, long live NeoVim", with a dash of disrespect for Bram and his goals of continued platform compatibility and coding style... I personally don't expect such acknowledgement.

Doing so might make Bram the 'better person', but I wouldn't blame him if it makes him a bit resentful.


What? I've seen tarruda and co. explicitly express gratitude and thanks to Bram.


By critiquing his reluctance to accept patches because he'll be stuck maintaining that code? By forking Vim and removing some compatibility and legacy support features when tarruda's multithreading patch was not accepted?

No, the core contributors have not been outright in their criticisms, but IMO the fork itself shows a lack of respect for Bran's work and a lack of willingness to work with him to make Vim better. And now tarruda has stepped back from NeoVim, perhaps recognizing himself the cost that Bram bears.

By simply contributing to the tests - one of the outright critiques of Vim itself - they could have brought a lot more confidence to accepting such patches to Vim, but they chose to take their ball and play elsewhere instead.

What frustrates me the most is that instead of two branches of Vim that are moderately better (with the future of one of the branches being left behind), we could have had one which was much better.


Way to misrepresent it. They made the async patch - it wasn't accepted. So they rewrote it to Bram's liking - still wasn't accepted. 5 rewrites further Bram says 'lol well actually I don't feel like accepting this PR at all'. Its very understandable to feel a bit of animosity after bending over backwards for someone with commit access and then after all the effort still having the PR refused. That's called being led on, and its ultimately a dick move.


People are free to fork open source projects. tarruda tried to merge the async job system before forking vim. Bram has the right to deny the patches, but the most successful projects are the ones that attract good contributors and don't depend on the output of a single coder. It's easy to say "just make vim better" without really trying to understand Vim's C codebase.

vim's source code is really hard to test. Refactoring is needed to make code testable. That's true for every project that doesn't have tests yet. Another thing that makes it really hard to contribute to vim is that it supports operating systems that don't even exist anymore. I really don't feel like spinning a VM to make sure my changes don't break it on MS-DOS. I would rather send a PR that removes MS-DOS support than support that.

https://github.com/neovim/neovim/pull/635/files


Except that the direction we were moving wasn't one branch that was much better, it feels like it was no improved branches at all.

vim7 was a great improvement, and when I show people the time travel capabilities it blows their minds. But that was a long time ago. With the number of people to whom vim is very important, I'm surprised there isn't more results coming out of it.

Though maybe it is mostly that the core doesn't need to change and innovation can happen in the plugins? That is certainly true to some extent, but the async stuff was way overdue.


I don't think this is a fair assessment. Before forking an attempt has been made 'to make vim' better. It's open source thus imho all is well if there are two source trees with different 'philosophies' (one 'a bit' centralistic the other more team-like).

Regarding cost. Most developers need to be paid. I read [here](https://groups.yahoo.com/neo/groups/vimannounce/conversation...) that Google provided (some) funding to Bram. With neovim initially there were lots of new things (clean-up, async, terminal), I don't see a problem if there should be a bit of slowdown now. It's a team. I think it's robust. I prefer Neovim and occasionally use MacVim too, thus grateful to Bram also. No need for frustration imho (but I'm glad there is neovim:)


Since Neovim started up, Vim has seen the most commits in a year ever. Competition makes things improve.


And some neovim patches are merged upstream.



I was surprised to learn that vim started out on the Amiga. Back in those days I was using DME, by a certain Matt Dillon (of Dragonfly BSD fame, not the actor ;-) ). At the time it was the only editor that could drag me away from Emacs. Ironic that Vim later seduced me away from Emacs again...


Incidentally, the Amiga Workbench Utility disk (or whatever they called it) included a very nice microemacs implementation:

http://www.guidebookgallery.org/screenshots/amigaos204

Suffice to say, I have been a very happy emacs user since then ;)


Cooincidental, not ironic.


Ironic in the sense that I could have been using vim the entire time.


Anybody using a neovim MacOS app [1]? I'm a huge vim user, but mostly via MacVim [2].

[1] https://github.com/rogual/neovim-dot-app

[2] https://github.com/macvim-dev/macvim


Well, I've been using Vim on iTerm 2 for a long time and have been trying neovim recently, but everything through command line, since it fits better with tmux


I use/have used neovim-dot-app, it's pretty nice. It's not quite as polished as MacVim, mostly little things like not having dock menu entries for creating/switching windows. I had to compile from HEAD fairly regularly to fix bugs and keep up with neovim releases. I mostly switched back to MacVim once vim 8 came out.


I've been very happy with neovim.app but recently switched to VimR. VimR switched to neovim some time ago. Haven't noticed any issues as compared to neovim.app. Both work pretty much the same for me as I don't use VimR's features.


Been hearing about VimR, I should really check it out.

I've used both Neovim.app and neovim-qt, but for reasons I've forgot, always end up back with MacVim.


I've been meaning to try neovim, but I'm so in love with evil-mode spacemacs. I only switched to evil-mode recently, but I can already tell that there's no going back from modal editing for me. Can anybody speak for benefits of using neovim over spacemacs?


Simplicity. It's just Vim, but with less suck.

Spacemacs is a huge complex mass of software on top of another. I could not digest it.

But, if you're already happy and productive with Spacemacs, it's unlikely you'll gain too much with Neovim.


I have to agree that Spacemacs is seriously complex. I first cam to it because I wanted to try Emacs coming from Vim/nvim but it suffered from prettt bad load times, a bad C/C++ story and a leaky abstraction over packages. I'm the end I configured Emacs from vanilla (with Evil mode!) and I've had a much better time. I've also picked up quite a bit of elisp, which is much much much better than VimL.


Start emacs-client at startup and you'll only have to deal with the load time on boot. Also, you can do a minimal Spacemacs install. It's not actually all that complex if you look under the hood, and a really nice thing about it is that you only have one dotfile to back up on a git remote or few.


Thanks for posting this, I was looking for something like that :).


I don't know if I am too old or just think differently than vim enthusiasts, but I somehow couldn't bring myself to like vim. Of course that's might be since I can't find motivation to dig into it further. As a developer I use it almost daily when doing something on the server, like editing some config etc., but I somehow always prefer a software, where you do things intuitively without needing to first learn a shortcut for everything. I just prefer Visual Studio or Visual Studio Code from Microsoft when developing code, accepting that I must use mouse and the editing process might take slightly longer. Also, as awkward as it might sound, visually vim looks a bit ugly to me and I never could get fully over it. :-)


> I don't know if I am too old or just think differently than vim enthusiasts

You make it sound like vim is a new thing. It's 25 years old. And vi is 40 years old. If you've been writing code for longer than that, then damn. I'm impressed.

> prefer a software, where you do things intuitively without needing to first learn a shortcut for everything.

Like what? ctrl + c or ctrl + v? I doubt anyone has every figured those out by themselves. They either read the documentation, or someone showed them. Or do you mean intuitive as in right click on selected text, and then click the copy option? to each their own, but I couldn't stand wasting that much time every time I want to copy or paste something.

> accepting that I must use mouse and the editing process might take slightly longer.

Kind of answers my previous question. But for me, it's not that using the mouse wastes an extra second here and there. But it breaks the constant flow of typing on the keyboard. I don't like that constant start/stop of switching between the keyboard and mouse. But you don't mind it, and that's fine. (I'm just explaining from my perspective, why people would prefer something like vim)

> visually vim looks a bit ugly to me

Everyone's tastes are different, but I don't understand this. It's just a cursor, the text you are working with, and a small bar at the bottom with some info. How is that ugly? I mean you can change the font to whatever you like.


> > prefer a software, where you do things intuitively without needing to first learn a shortcut for everything.

> Like what?

Like mouse-select, copy, paste. Once learned (however that happened, however long ago), it works across virtually all OS/gui combos (except gvim without knowing vim :), and you can immediately get something done. If you're dropped down into an environment, and have to get something done, using your slow but working general methods is pretty attractive, compared to having to learn a whole new way of merely copy/pasting before you've done a single thing.

Having used vi, and later vim, since the mid eighties, it can be painful for me to sit with someone as they mouse around cutting, copying and pasting. Watching someone reversing the order of two lines, or two characters, with a mouse is really frustrating. But they're getting something done, focusing on the task instead of the how, and beyond an offer to help them with vim if they like (they usually don't), I just sit there and accept.

I like my mouse, I'm just glad it's not all I have. But keep in mind, it's really frustrating for someone to have to listen to someone else telling them "you can do this a better way!". It's just meta distraction.


Copy and paste? Reordering two lines or two characters?

If that's all that vim could do better than traditional editors, then sure, stick with the traditional editors. Learning the complexity of vim is not worth it.

But those are incredibly trivial examples. vim can do so much more than that, in a really efficient and powerful way.

It's like demanding why one should use a battleship when a tricycle can also turn left and right, and can go forward and backwards. Yes, both can do that, but the battleship does far, far more, and there are reasons for its complexity.

If all you need is a tricycle, stick with the tricycle by all means. It's much more intuitive than a battleship. But some of us need far, far more power than that.


You can totally enable mouse selection if you like:

  set mouse=a
  set ttymouse=xterm2
You may have to enable your terminal's mouse support, if you're running Vim in a terminal.


> but I somehow always prefer a software, where you do things intuitively without needing to first learn a shortcut for everything.

As the quote goes, "The only "intuitive" interface is the nipple. After that it's all learned."

The word you're looking for is "different". Vim (and Emacs) have different shortcuts than what you're used to from Windows. That's because they're much older. Vi and Emacs actually predate those "intuitive" shortcuts of yours.

And like with many things our industry standardized on these days, just because it's popular, doesn't mean it's not utter shit.


Everyone says that about nipples, but anyone whose had a kid knows that its not always easy for a baby to learn how to latch onto a nipple. It can take a day or two and all they while you are terrified your baby is going to starve.


> "The only "intuitive" interface is the nipple. After that it's all learned."

I did not know this saying, thanks. This explains why I cannot work on a GUI without a track point!


I was thinking the same thing. The trackpoint is the only kind of pointer I enjoy using. Although at one point I had a keyboard with a built-in trackball, that wasn't too bad either.


I hate those things! I've never been able to get the desired effect, except almost by accident, just like everything else in life that looks like those things. Total mystery.


Like with everything worthwhile, it takes training :).

I used to scorn trackpoints until my friend told me he's very fond of them - that convinced me to give it a try. They're not bad. Play with one for 5 minutes (to the clock), and you'll be liking them more than touchpads :).


> As the quote goes, "The only "intuitive" interface is the nipple. After that it's all learned."

But many babies have trouble latching and the mother and baby need some assistance with the first few feeds - i.e. even nipples aren't totally intuitive.


> Vi and Emacs actually predate those "intuitive" shortcuts of yours.

Yes, but that is different, since in "normal" IDE, I dont need to use shortcuts for everything. In vim, you must learn how to select something, then how to copy it and how to paste it. In an IDE, I just select it with mouse, since in all other software I also select the exact same way, and shortcuts are only ctrl-c ctrl-v. Of course I also use other shortcuts, like F2 and ctrl-F2 for bookmarks, but normally I don't need them for everything.


First off, there's a lot of good reasons to use V.S. OK, Now that that's out of the way...

The one thing I see people cite the most when they talk about not learning vim is "shortcuts". Vim's main editing interface is not "shortcuts". It's an editing language. There's a huge difference:

https://www.youtube.com/watch?v=ZdC2ysrP-XA

(not trying to flame or boast or anything, just trying to honestly communicate my feelings here, but) Anytime I use an editor that doesn't have a similar model, it feels like trying to carve wood with a coffee mug. If that simile sounds weird and doesn't make sense, that's how it feels.

The second argument I hear is plugin/ide functionality. You can get syntax highlighting, linting, VCS integration, anything from the shell, C-Tags, plugins, in vim but a lot of the refactor type IDE stuff isn't up to snuff. I have a theory about this. In a regular IDE, refactoring manually is a pain point. This means the auto-refactor tools are more polished in IDEs. I do as many refactors that could be automated as any other programmer, but its not a pain point because manually refactoring in vim takes only marginally more thought/input than automatically refactoring in an IDE.

Not saying that IDE refactoring isn't better (it is), but it isn't a big enough productivity improvement for me to fix that versus, say, refining my vim mappings, or practicing using the git plugin vs always using CLI git, or finally integrating the tmux plugin, etc.

Now... THAT said. The onboarding process for vim is pretty awful. You either start with an austere text editor and piece by piece build it into an amazing IDE/text editor, or you start with a premade blackbox config that you are unequiped to tweak.


Pretty sure that's not a simile.


Analogy?


IMO, the problem is that we've tried to use Vim as an IDE. Vim's power is modal editing and the composable grammar. I think Vim should be in competition with the text editor widget that sits inside VSCode, Atom, Xcode, Intellij or any other IDE instead of the IDE itself. Fortunately, with neovim this will be possible.

People can use IDEs of their choice but use real Vim for all text operations or just stick to vim like me :)


It was possible a long time ago (pre-VS 2003) to embed a real copy of gvim as an OLE widget inside Visual Studio. I'm looking forward to being able to do that in a less hacky way via neovim.


> I somehow always prefer a software, where you do things intuitively without needing to first learn a shortcut for everything

That doesn't even apply for an IDE. As a vim user I always feel lost in those at first.

Any tool with a bit of power will require familiarization. You won't get the most out of that IDE unless you learn it.


I'd argue Vim is actually the intuitive choice because its commands allow motion/editing across boundaries that make sense, without (in my opinion) awkward mouse/cursor motions. For example % at a function call will edit/select the whole call if the cursor is at the beginning of the function name.

Once you have the muscle memory, you use little thought on how to mechanically accomplish editing tasks, so the intent-to-accomplishment pathway is quite direct. In the end though this may not be the case for you, even if you earnestly dove into it.

I think the main difficulty with learning Vim is that its commands are like minimal "combinators" attached to arbitrary keys, and they take exploration/use to experientially bubble up these combinators to reach "comfort parity" with standard editors. In this way Vim is like the Lisp of editors.

About the ugliness, I agree. That's why I usually use a GUI version if I can. Plus it must be reiterated that Vim is more just a text editor, not an IDE like Visual Studio. If I could use VS+VsVim for everything, I would.


"About the ugliness, I agree."

I understand how pleasant it is to use a tool that you spend a lot of time in day in and day out that is beautifully designed and just looks and feels nice. I remember slightly drooling at how some fonts in a competing editor seemed to have a subtle glow. I would have liked to have that in vim, and maybe it is possible. There are some other GUI improvements that could make it look/feel nicer.

However, as a power user give me function over form any day. It's like the choice between taking a long, beautiful path vs a short, ugly one. Or maybe the long beautiful path can't even go where the short ugly path goes.

Most of the time, I'm using my editor to get things done, and done as quickly and efficiently as possible. I'm not using it to admire how beautiful my editor looks or show its looks off to friends.

If I have a choice between getting my work done in 2 seconds vs 5 minutes, I'll choose the 2 seconds. There must have been hundreds of times in my life where I've done a really complex set of editing tasks in vim (or emacs) in a couple of minutes that I know would have taken me hours and driven me insane in a traditional editor.

After learning vim (and emacs) being forced to use a traditional editor is like cutting off my arms. It's like being forced to drive a car that can go only 5 miles an hour and only make 90 degree turns. Super painful and it may not even be capable of doing what you want, and certainly not quickly, efficiently, or pleasantly. Though certainly the more sophisticated traditional editors are far better than primitive traditional editors like notepad or nano (though some people still swear by those and will not even think of leaving them!).

It's really hard to get across to people only used to traditional editors the sheer power that vim and emacs have. It's something that you really have to be a veteran of these editors to fully appreciate -- and that usually takes years.


In terms of doing things intuitively -- I think (maybe incorrectly) that you mean seeing icons that you can click on to perform a certain action rather than the keyboard command that does the same. If so, that is easy to fix by adding buttons. The problem with this approach is that mouse-driven commands are almost never "mouse-only" -- you still need to move the hands back and forth between keyboard and the mouse (e.g., after you click "save as" you need to type the file name to save to) and this wastes quite a bit of time.

But people are different, some prefer it this way and some not. Even on the keyboard-driven side there is a clear divide between those who like single-mode interface of Emacs and those who love Vim and hate the pianist training of Emacs multi-finger actions.


I've been using Emacs for years now but since I got introduced to PHPStorm I must say I won't ever use Emacs for PHP again. It's features are so addicting that I don't mind not having the shortcuts I'm used to.

I was never an IDE guy but PHPStorm is just too good, so much time saved.


php in emacs is pretty lacking, I wanted to try the spacemacs layer with these additions https://github.com/syl20bnr/spacemacs/pull/3943/files but after using jetbrains ide for a while i am not really motivated :p, I wish they released an headless version to plug it in whatever editor like eclim does :(


It can vary with time and context. I had a long period where mangling text in high prowess was important to me. Because I was somehow in love with programs, and doing lots of things with my fingers felt good and worthy. Also because I was using Java, very verbose as everybody knows.

Some people will love Java and accept its verbosity, I cannot.

Now I found out about lisps, ml, or even ruby and suddenly verbosity decreased.. you need less text edition.

And even more than that, focusing on algorithms and conceptual structures makes you forget about editing, formatting, or even live check etc. You often think deep beforehand. Then type a few things, because the design is more balanced.


There are really good vim plugins for visual studio so it's not an either or proposition. Vim keybindings are simply a much faster way to edit code.

What's less intuitive? caw stands for change a word. This selects the word and deletes it leaving you in insert mode to type something new.

Or: ctrl left arrow, shift, ctrl right arrow, delete key.

cit stands for change inside tag (html tag) or ci" for change inside the double quotes. dit and di" work just the same and vim can be thought of as a language to work on text.

If you have a few min to spare to see why it's so powerful and not that hard to learn you can google "you don't grok vim" to get a good stackoverflow response on it.


>where you do things intuitively without needing to first learn a shortcut for everything.

you can learn that intuition easily by learning 'vim language' , there are no shortcuts.


I use vsVim which is a vim plugin for visual studio, so I get the best of both worlds :)


Sadly, vsVim doesn't properly handle the undo history, so pressing `u` often ends up just deleting single characters instead of what was changed during an insert mode session.

ViEmu though, is fantastic.


Try the VSVim plugin, it's good software.


There is a vim plugin for VS ;)


> Bram admitted to using other editors on rare occasions, and said he always misses the dot (.) command, which repeats a change several times in different positions, and the ability to record and replay a sequence of commands.

> “Just a simple ‘change this text into that text’ can be very laborious without a repeat command,” he said. “I haven’t seen another editor that provides this feature.”

Note that emacs has had the repeat command since version 20.3, released 19 August 1998[2]. I suppose that means he's not used it since then …

[1] https://www.gnu.org/software/emacs/manual/html_mono/efaq.htm...

[2] https://www.emacswiki.org/emacs/EmacsReleaseDates


Have you used vim? . is much closer to running a keyboard macro than it is to C-x z - only you don't have to record anything ahead of time, nor necessarily even realise until afterwards that you might want to reuse what you've just done. There's no precise equivalent in emacs. It's described here: http://vim.wikia.com/wiki/Repeat_last_change

C-x z is lame by comparison. Like, suppose you just typed in M-d h e l l o, and you press C-x z. It repeats the last command: self-insert-command. So you get an additional o. Thanks, Emacs!

More comedy: after you move the cursor, perhaps planning to use C-x z to insert another o elsewhere in the document, C-x z now replays the last cursor movement command.

(None of this is illogical, it's simply that C-x z is not, probably, very useful for editing text.)

With vim, on the other hand, pressing . would replay the word deletion, followed by the insertion of "hello". And you can use other motion commands to move about the file before repeating it again, allowing you to perform this operation in multiple places.


https://github.com/wyrickre/dot-mode, elisp is pretty awesome if you utilize cl-lib and eieio.


No, this is just a clickbait article.


I found the article on vim.org:

> Nice article about Vim on hostingadvice.com

> Releasing version 8.0 and getting close to the 25th birthday inspired the writing of this article. It contains links to relevant info and can be used to convince a friend to start using Vim. (Bram Moolenaar)


So, what does he think about Emacs?


There is an answer in the video at 1:06:11. "In some way it's actually nice to have competitor [he is speaking about Neovim] and Emacs has disappeared, so.. [I think, he smiles at this point]".


Does anyone know what vim plugin or feature is pictured in the illustration? The code outline on the right side?


Looks like tagbar to me https://github.com/majutsushi/tagbar



Too bad most of the new features are already in Neovim.


Why is it bad? Competition is always a good thing, and I'm glad that Neovim urged Braam to improve Vim as well.

Personally, I'll rather use Vim as it focuses on stability and long-term compatibility. I have a huge respect for Braam for maintaining the project for so long. On the other hand, some of the Neovim's promises are just that, big dreams. Development on Neovim has slowed down and if you look at their git history, you'll see most of their commits are actually upstream patches taken from Vim.

I also see a lot of hate towards Vim source code and code styling, which is not that bad and I actually prefer it to Neovim's two spaces per indentation style.


Wow, hundreds of developers and 7 newsletters!1!! has Netcraft already confirmed that Vim is obsolete?


We've banned this serial troll account. Please don't create accounts to violate the guidelines like this. We detached this subthread from https://news.ycombinator.com/item?id=13237170 and marked it off-topic.

https://news.ycombinator.com/newsguidelines.html


Just past month and that too after Neovim lit a fire under Vim. The difference would be much bigger if you check for a period of last 2 years or so.

Neovim: https://github.com/neovim/neovim/pulse/monthly

Vim: https://github.com/vim/vim/pulse/monthly

I don't know why people feel emotional about Vim. Neovim is just Vim with a breath of fresh air.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: