I hope that language servers fully take off. This way, Vim and Emacs can gain semantic autocomplete & navigation. To be clear: it's not that they can't have that in principle, it's just that engines for semantic operations are difficult and expensive to write, so they were made primarily by IDE companies - and until recently, it meant they were tied to those IDEs.

With that, the only remaining thing in which IDEs are a better choice than vim or Emacs is debugging. I wish for decent and fully featured debugging TUIs.

I've never been a big debugger user, but I thought if you like LSP, you might be interested in Microsoft's analogous debugger protocol:

https://code.visualstudio.com/api/extension-guides/debugger-...

I imagine Emacs, vim, and friends could implement their own frontends for this, much as has been happening with LSP.

Wow, thanks!

And it turns out, Emacs and vim do implement their own frontends for this - [0], [1]. My wish just literally came true!

[0] - https://github.com/emacs-lsp/dap-mode

[1] - https://github.com/puremourning/vimspector

Awesome - glad to be of assistance!

> Navigation is rarely the limiting factor in development speed

Here in spaghetti enterprise land it is. Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base.

And since we decided to split a single bowl of that spaghetti into nuget packages the more "primitive" tools like ctags are the best way to navigate the project, they don't care about pesky things like dll boundaries.

> Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base.

Isn't that a test coverage issue more than a navigation issue ?

Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.

Code coverage is really high, legend has it that code coverage was tied to bonus a decade ago. The tests typically add more mental overhead than reduce it due to this.

> Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.

It doesn't solve it, but it makes it quicker and easier to navigate, it's not just the shortcuts but the navigation stack (go to declaration, go to declaration, go to declaration, pop, pop, got to declaration, pop, pop, etc) that make it easy. Tmux and/or vim are also much better at multi-window editing than IDE's which is also handy.