3 ms·

I think VSCode is a very mouse-centric experience. Using Emacs I don't touch my mouse. It's a far more efficient and comfortable (less straining) experience, fo

I think VSCode is a very mouse-centric experience. Using Emacs I don't touch my mouse. It's a far more efficient and comfortable (less straining) experience, for me anyway. I use both Emacs and VSCode but vastly prefer the Emacs experience. I also use Emacs for much more than simply writing code. Emacs is also more pleasant to use because it's simply faster. VSCode is slow compared. I'm not talking about application startup time, but just about every operation you do. VSCode stutters and hitches all over the place. Input latency might also be worse, but I don't know, that's just what it feels like. It also lacks many of Emacs' powerful features like helm swooping, which is of course customized just the way I like it. VSCode's "search in all files" just doesn't cut it. And symbol fuzzy search is just for symbols, not all text. Code navigation in Emacs is lightning fast, with the right setup. My Emacs config makes a distribution tailored for me. A great advantage Emacs used to have over other IDEs and some editors was that you would use it for all/any language. Now with editors like VSCode, which has great support for many languages, it has lost this advantage.

cdrini 6y ago
Although the mouse centric experience thing makes sense when _writing_ code, I don't think it makes as much sense for reading/refactoring code. I'm not an Emacs user, but watching some of my colleagues navigating a codebase with Emacs looks not only slow, but also very mentally taxing. They often switch to grep searching, then select the results in order to iterate over them in Emacs. Or they have to remember full paths to files (with autocompletion, but still). Ctrl-shift-f in Vs code looks significantly faster since it displays the results in real time and let's you see the snippet and simply click on the one you want. Also ctrl-p for finding a file quickly by searching for any part of the path. Ctrl-clicking on a method name to jump to its definition. Right click > rename to rename a symbol across files. Or a feature I love in Pycharm, alt-enter to auto import a function--without having to try to remember where it's coming from (it gives a drop-down for multiple definitions). These things speed up flows enough that I think it outweighs the cost of having to remove your hands from the keyboard. And I think reading/refactoring code is as important as writing code in development.
- erikbye 6y ago
  These are exactly the things I find better and faster in Emacs. Watch video below and imagine searching that way but for all files in your project. Results in real-time, instantly taken to content when you highlight and browse results with arrow keys or further narrow down by typing. https://www.youtube.com/watch?v=RfasCCuCEgM https://www.youtube.com/watch?v=RfasCCuCEgM IMO VSCode's ctrl-shift-f doesn't come close. And its symbol search is just for symbols, not all text.
  - cdrini 6y ago
    Oh nice! That's pretty similar to the VS Code's search experience; I didn't know emacs had that built in! I have a colleague who uses emacs and he always uses grep for stuff like this and it makes my eyes bleed :P
williamdclt 6y ago
Never used emacs, so can't compare. But: > I think VSCode is a very mouse-centric experience I never touch my mouse in VSCode. There's many many shortcuts that are configurable, and keyboard navigation isn't not a "second-class citizen" > VSCode is slow compared Yeah, probably true. Never felt like it slowed me down though > And symbol fuzzy search is just for symbols, not all text cmd-t on vscode. Probably not strictly equivalent to helm-swoop, but you could make your own extension in JS (which is a strong point for many people, I don't particularly want to learn a language that's specific to my editor).
- erikbye 6y ago
  > cmd-t on vscode. Like I said earlier, that's just for symbols, so no, it's not the same.
  - Dayshine 6y ago
    So, I write a niche language server along with an adapter for VS Code. What are you frequently jumping to that isn't a symbol? I can expose anything through the LSP api. Thinking about it, every single piece of text is covered by symbols and falling back to find all references. The only thing that wouldn't work is trying to jump to syntax, but why would you do that?

cdrini 6y ago

Although the mouse centric experience thing makes sense when _writing_ code, I don't think it makes as much sense for reading/refactoring code. I'm not an Emacs user, but watching some of my colleagues navigating a codebase with Emacs looks not only slow, but also very mentally taxing. They often switch to grep searching, then select the results in order to iterate over them in Emacs. Or they have to remember full paths to files (with autocompletion, but still). Ctrl-shift-f in Vs code looks significantly faster since it displays the results in real time and let's you see the snippet and simply click on the one you want. Also ctrl-p for finding a file quickly by searching for any part of the path. Ctrl-clicking on a method name to jump to its definition. Right click > rename to rename a symbol across files. Or a feature I love in Pycharm, alt-enter to auto import a function--without having to try to remember where it's coming from (it gives a drop-down for multiple definitions). These things speed up flows enough that I think it outweighs the cost of having to remove your hands from the keyboard. And I think reading/refactoring code is as important as writing code in development.

erikbye 6y ago
These are exactly the things I find better and faster in Emacs. Watch video below and imagine searching that way but for all files in your project. Results in real-time, instantly taken to content when you highlight and browse results with arrow keys or further narrow down by typing. https://www.youtube.com/watch?v=RfasCCuCEgM https://www.youtube.com/watch?v=RfasCCuCEgM IMO VSCode's ctrl-shift-f doesn't come close. And its symbol search is just for symbols, not all text.
- cdrini 6y ago
  Oh nice! That's pretty similar to the VS Code's search experience; I didn't know emacs had that built in! I have a colleague who uses emacs and he always uses grep for stuff like this and it makes my eyes bleed :P

williamdclt 6y ago

Never used emacs, so can't compare. But: > I think VSCode is a very mouse-centric experience I never touch my mouse in VSCode. There's many many shortcuts that are configurable, and keyboard navigation isn't not a "second-class citizen" > VSCode is slow compared Yeah, probably true. Never felt like it slowed me down though > And symbol fuzzy search is just for symbols, not all text cmd-t on vscode. Probably not strictly equivalent to helm-swoop, but you could make your own extension in JS (which is a strong point for many people, I don't particularly want to learn a language that's specific to my editor).

erikbye 6y ago
> cmd-t on vscode. Like I said earlier, that's just for symbols, so no, it's not the same.
- Dayshine 6y ago
  So, I write a niche language server along with an adapter for VS Code. What are you frequently jumping to that isn't a symbol? I can expose anything through the LSP api. Thinking about it, every single piece of text is covered by symbols and falling back to find all references. The only thing that wouldn't work is trying to jump to syntax, but why would you do that?