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.

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

IMO VSCode's ctrl-shift-f doesn't come close. And its symbol search is just for symbols, not all text.

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

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).

> cmd-t on vscode.

Like I said earlier, that's just for symbols, so no, it's not the same.

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?