7 ms·

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

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.

slimsag 9y ago
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?
- nerdponx 9y ago
  Vim can be really slow with too many plugins running.
  - ssijak 9y ago
    There is parallelism in new vim now
  - antod 9y ago
    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.
    - baldfat 9y ago
      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.
    - nerdponx 9y ago
      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.
      - antod 9y ago
        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 :)
- pbiggar 9y ago
  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.
  - iaml 9y ago
    iterm has terrible latency, you should try using alacritty - way faster.
    - pbiggar 9y ago
      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.
    - phaedrix 9y ago
      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."
  - Tehnix 9y ago
pjmlp 9y ago
It is surely faster than Atom, but not on the same league as sublime, emacs or vim.
- sandos 9y ago
  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!
  - pjmlp 9y ago
    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.
- barrkel 9y ago
  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.
chuckdries 9y ago
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.
- StevePerkins 9y ago
  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.
baldfat 9y ago
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.
- Tehnix 9y ago
  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 :/
  - chillee 9y ago
    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 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 https://github.com/VSCodeVim/Vim/pull/1897 or https://github.com/Chillee/VSCodeNeovim https://github.com/Chillee/VSCodeNeovim. Those should provide a much higher fidelity emulation.
    - Tehnix 9y ago
      Ah, that would certainly make sense. Is there any logging anywhere when such a thing occurs so one could help dissect the issue?
      - chillee 9y ago
        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.

slimsag 9y ago

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?

nerdponx 9y ago
Vim can be really slow with too many plugins running.
- ssijak 9y ago
  There is parallelism in new vim now
- antod 9y ago
  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.
  - baldfat 9y ago
    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.
  - nerdponx 9y ago
    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.
    - antod 9y ago
      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 :)
pbiggar 9y ago
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.
- iaml 9y ago
  iterm has terrible latency, you should try using alacritty - way faster.
  - pbiggar 9y ago
    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.
  - phaedrix 9y ago
    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."
- Tehnix 9y ago

pjmlp 9y ago

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

sandos 9y ago
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!
- pjmlp 9y ago
  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.
barrkel 9y ago
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.

chuckdries 9y ago

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.

StevePerkins 9y ago
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.

baldfat 9y ago

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.

Tehnix 9y ago
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 :/
- chillee 9y ago
  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 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 https://github.com/VSCodeVim/Vim/pull/1897 or https://github.com/Chillee/VSCodeNeovim https://github.com/Chillee/VSCodeNeovim. Those should provide a much higher fidelity emulation.
  - Tehnix 9y ago
    Ah, that would certainly make sense. Is there any logging anywhere when such a thing occurs so one could help dissect the issue?
    - chillee 9y ago
      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.