Hacker News Reader

Comment by pbiggar | Hacker News Reader

I tried VS Code for a few weeks and really liked it. In particular, it's super super fast (compared to vim, spacemacs, emacs and atom, all of which I've used in recent history). It's by far the fastest and smoothest text editor I've used and I was sad to leave it.

I left it because the Vim mode is completely unusable. None of the commands work like you expect them to, undo was broken and I'd periodically lose my undo history. Everything was just a little bit wrong. Which is a shame because it's otherwise a really fantastic editor.

View on HN

You found it to be fast in comparison to vim and emacs? I am surprised to hear someone say this. I also think it is plenty fast for my needs, but certainly not faster than vim or emacs.

Did you mean fast in terms of performance, or in terms of your ability to edit, or something else? And you weren't using a GUI version of vim/emacs, right?

Vim can be really slow with too many plugins running.

There is parallelism in new vim now

I've also noticed that it's slow on Macs for some reason too. The same set of plugins don't seem to cause a slowdown on Linux.

Thank you! I have a HUGE bias against Apple in general but when I am using a Mac I have always find it laggy compared to my Linux and even Windows terminals.

That's very strange, it seems to be the case for both Vim and Neovim, and it doesn't depend on the terminal or shell I'm using. Is it just something inherent in the Mac environment then? I was always left scratching my head over the number of plug-ins people used, wondering how the program was even functional for them.

I don't really know, as I haven't looked into it much. But my vim config is in git and shared between Linux and Mac laptops. On Linux (2013 Thinkpad) I can't really detect much lag at all, but on the Mac (2015 MBPro) it's really quite annoying - to the point it subjectively seems about as "slow" as Atom. Interactive things like scrolling are especially annoying - non interactive things seem ok though.

I'm no Vim or Mac OS poweruser though - I've just kinda put up with or avoided it. Sorry I couldn't really offer much beyond confirmation :)

Yes, absolutely. I'm running vim in iterm2, and I haven't had time to figure out why it's slow. Things that are really slow in vim are scroll speed, a 1s-ish pause when ALE fills the quickfix window, and an undiagnosed merlin-related pause when opening ocaml files.

So scrolling is slow. Terminal related? Maybe - terminals are slow. But when highlights an error in elm or ocaml code, scrolling becomes unusably slow (not that it's really that fast otherwise).

By contrast, no plugin I loaded made VS Code slow, and it was super smooth and fast to do, yes, scrolling, all the time.

My current emacs is via spacemacs, and I'm only using it for magit. Apart from asking me to update .recentf EVERY SINGLE TIME I refresh magit, it also takes a very noticeable pause to update the git status. By contrast, that was completely backgrounded in VS Code (though I didn't really use it since I prefer magit, so apples and oranges comparison here).

TL;DR: vim is not fast, especially not if you want to do something like use it in a terminal with plugins. VS Code is actually really fast.

iterm has terrible latency, you should try using alacritty - way faster.

I did, but it didn't work all that well for me. I just tried it a minute ago. However, I found that macvim was way better for me, once I figured out how to make it look as pretty.

Unfortunatley Alacritty has the same issues:

From Alacritty's FAQ: Q: "macOS + tmux + vim is slow! I thought this was supposed to be fast! This appears to be an issue outside of terminal emulators; either macOS has an IPC performance issue, or either tmux or vim (or both) have a bug. This same issue can be seen in iTerm2 and Terminal.app. I've found that if tmux is running on another machine which is connected to Alacritty via SSH, this issue disappears. Actual throughput and rendering performance are still better in Alacritty."

I definitely share the sentiment that Spacemacs is slow, which annoys the crap out of me (for a lot of things it feels less performant than Atom/VSCode because people don’t write things in an async way in elisp often it seems).

With regards to vim though, there is no reason for it to be slow, except for some specific plugin pulling you down. Are you using synchronous linters? I thought Ale was async. I would also recommend vim-plug and lazy loading for plugin management.

I’m on Mac myself and use vim regularly in iTerm, Terminal.app and Gui, and am currently not experiencing any problems. Of course, environments vary.

Also, you can try switching out your vim with neovim, which should work seamlessly.

It's not just plugins slow Vim down, a few things that come with Vim are slow too.

The worst is probably language specific support for LaTeX files, particularly syntax highlighting, there is even a tex-slow (http://vimdoc.sourceforge.net/htmldoc/syntax.html#tex-slow) entry in the Vim manual. On my old netbook (haven't heard that word in years!) it was so bad Vim lagged behind my typing, and I'm not particularly fast. I turned off syntax highlighting which fixed the lag, but missed it so much I switched to Emacs instead (and discovered AucTeX which is fantastic, so I wouldn't switch back now).

The vim emulation plugin has gotten better recently, IMO it's the best I've seen in a GUI editor. The undo history thing sort of persists because the vim plugin maintains a different undo history than vscode. They implement undo branches whereas VSCode's native undo stack does not, and the native stack only sees large chunks of changes instead of individual actions.

I'm actually working on a fork of VSCode that rewrites their native undo stack to support branching and more granular control so the vim plugin can sync to it and not maintain two undo histories. We're hoping to submit a PR for that soonish, as soon as school stops kicking my butt.

I'm not sure about the boundary where "editor" ends and "IDE" begins, and I'm not sure which side VS Code falls on at this point.

Either way, I think it worth mentioning that the Vim emulation plugin for JetBrains' products is truly the best out there... and a great milestone for others to strive toward. The scope of what's emulated (including Vim-style search and replace), the ability to cherry pick which keyboard shortcuts use Vim mappings and which use the native editor mappings, etc.

In my humble opinion, IntelliJ is a better Vim than Vim is. I noodle around with VS Code here and there... but it's approaching an uncanny valley point where it's too heavy for use as a plain text editor, but not able to compete with WebStorm (or whatever) as a web IDE.

It is surely faster than Atom, but not on the same league as sublime, emacs or vim.

Emacs, at least in windows, can be surprisingly slow. I think they have fixed some issues with long lines, but those used to be aweful. Also large files can be slow. Also, too many packages is a problem, which we might well see in the future for VS code, too, but the javascript runtime is likely orders of magnitude faster than the emacs one, no?

vim, on the other hand, is supposed to be really quick as far as I have heard!

I only use Emacs on UNIX systems and it is quite fast.

On the old days I was usign XEmacs, which did not had any issue with Windows.

Now if someone is running Emacs as cygwin application, then it might be slow I guess, given that everything on cygwin is slower than pure Win32 applications.

Emacs modes normally use regular expressions for everything from syntax highlighting to semantic insights. This does not make it fast. Emacs performance usually degrades linearly with the size of the file being edited, and most CPU activity occurs synchronously and blocks the UI.

I don't think Emacs is a fast editor unless you run it bare with -Q, at which point you've left out all the stuff that makes Emacs useful.

IMO it ought to provide a state machine engine for modes to use to do syntax highlighting, something that it can cache at line boundaries, stop and start electively depending on bit of the buffer is displayed in the current window, evaluate the state machine on a background thread (so, concurrent with actual usage, unlike the idle work it already does), etc. A state machine without extra knobs would only provide lexical highlighting, but I think extra knobs (e.g. variables, stacks) could be added to make it more useful.

The retained mode text styling with font locking etc. is not the optimal design choice for performance, I suspect.

I find VS Code VIM to be the best outside of well VIM and getting better.

I am thinking that in the near future the brain bending of Neovim inside of the a text editor VS Code ecosystem will happen. They already are putting parts of Neovim inside of VS Code editor in the last patch.

I just can’t put my finger on it, but in VSCode I very frequently end up in a weird vim state where I just have to hit escape until it resets to normal mode. There just seems to be a lot of corner cases or something that I end up hitting frequently.

And I’m fairly certain that is not on my part seeing as both vim itself, Spacemacs and Atom’s vim mode work superbly for me. It’s one of those things where VSCode just ends up irking me too much and I switch back to other editors :/

I suspect what you're running into is some kind of crash when running a command. I will say that I don't think we're doing a very good job handling errors, and I suspect it's that most users don't report them (they just press <Esc> and it goes back to normal).

For example, this: https://github.com/VSCodeVim/Vim/pull/2087

Either way, if you're ever interested in heading back to VSCode and felt disappointed in the Vim mode, check out the progress of https://github.com/VSCodeVim/Vim/pull/1897 or https://github.com/Chillee/VSCodeNeovim. Those should provide a much higher fidelity emulation.

Ah, that would certainly make sense. Is there any logging anywhere when such a thing occurs so one could help dissect the issue?

If you try opening up dev tools when that happens, it's likely the issue will pop up.

Honestly, there's several places that from an engineering quality standpoint bother me quite a bit. Performance on rapidly repeated actions is one. We have a couple race conditions too. A bunch of inproperly handled errors is another.

However, most of these don't really impact most users most of the time. If you're using vim, you're probably not holding down `dd` or rapidly typing actions one after a while. Similarly, as errors are separated into their own action and are captured at the top level, hitting escape is usually enough to get you back to a usable state.

Reply on news.ycombinator.com