- code "peek" (that little windows is super useful)
- good integration with debugger (again, vscode kills it here). For example: how to look a at a numpy array in emacs (in vscode there's a data viewer for that)
- robust LSP (for example, when I complete a formatting string f"{... on a big file, emacs simply becomes unresponsive for a minute or so (it's much quicker ona powerful computer though); pylance is simply superior on edge cases.
But although I'm a long time emacs user, there's one thngs where VSCode is much better, it's discoverability. I've learned much of what I need in 2-3 weeks, without ever looking at a manual.
Note: I'm a regular emacs user since since about 10 years (I came for the freedom, stayed for the community). I'm using VSCode since about a year.
I'll be happy to ear a way to make my emacs better.
But I think most people don't care about it enough because they either never close Emacs and/or use it in server-mode where emacsclient is pretty much instantaneous. Can I ask why you don't like doing that?
So having things take time on start up is an annoyance to me (but I live with it, I was just saying that emacs is slower than VSCode)
I’m sure vscode would chew through resources during a heavy session, have you benchmarked more than just the startup of the application?
You're right: once VSCode is in memory I think it uses more of it. But that's barely nothing when compared to rust-analyzer (which emacs LSP uses too).
However, I also have many plugins installed, so it might be just that. I wonder if it is possible to install a separate instance of Emacs, then I would be able to test the performance without all the plugins and configuration.
With lsp-mode it has that little window: https://emacs-lsp.github.io/lsp-ui/#lsp-ui-peek
Personally I use eglot with consult which temporarily switches the entire buffer to do the "peek" functionality rather than popping up a tiny window: https://github.com/minad/consult
who ever does such a thing? Emacs starts up on my machine soon after I login. It remains open until I logout. Current instance has 123 buffers (files). Loading speed just isn't important to me as a full-time native (C++) developer.
> - robust LSP
I tried LSP a bit. Gave up because it just didn't really help me with my actual work. Could understand why someone with less experience programming would find it helpful, but it just wasn't so for me (I use emacs dynamic completion a lot)
I use LSP a lot (through eglot with Emacs-29). For each "mode" in Emacs there are alternatives to LSP, mostly what was there before LSP, which may be equally good. However, I found that switching to LSP simplified my setup, and having the same functionality/keybindings between modes is great, e.g. my projects switch me between Python, Rust, and Java, earlier that was basically three different "IDEs", while today they're very similar.
yeah, but i don't give a damn. I do this once every few weeks.
ps. also, emacs is < 3 secs on my system, so even if i did care ...
Have you considered the possibility that people with more experience programming than you might find it useful?
I appreciate that people who started programming with such tools probably come to rely on it the way I rely on dynamic completion in emacs (which is a lot).
For what it's worth I'd use CLion for C++, most likely, if I ever wanted to go back to C++ outside of tiny sandbox projects.
P.S. Language servers are great for smaller ecosystems where no one can really afford to make or fund much beefier tools like IDEs, so a language server can be created by a community member and be used with pretty much all relevant editors almost instantly, meaning the ROI for the community is massive.
It's great for completing variable names, but also if you writing just regular text, finishing longer words and so on.
M-x dabbrev-expand
which is bound to M-/ by default (and yeah, I love it). Though I do like the context sensitive completions that lsp provides as well. They are particularly good for showing you structure members (since the language server knows the types).