![]() ![]() The plug in eco-system isn't as broad as that for VSCode, but unsurprisingly there's more cruft there, too. but so what? That might well be a strength since some kinds of changes can be low value & highly disorienting. Also, I do a lot of PostgreSQL related stuff and I've yet to find a syntax highlighter that's 1) just syntax highlighting and 2) able to handle things like dollar quoting well for VSCode where in Sublime Text I've had such highlighting for years. Some of the small differences around cursor/multi-cursor management never stop irritating me in VSCode compared to ST. For me its mostly speed and a number of small, but frequently encountered, quality of life issues that keep me coming back to Sublime Text. I switched from Sublime Text to VSCode and stuck with VSCode for months, and depending on project du jour I've done this a couple of times. Get off my porch, whippersnappers, etc etc. Perhaps the same sort of jaw-drop that occurs when someone takes a naive python app to go or rust and discovers that python is in fact actually really slow (whether or not it's "fast enough")? I'm sure there's an element of people not knowing what's been lost, and an element of people not understanding just how inconceivably fast computers are today, but it's hard to wrap the brain around anyone tolerating this (as customers, as purchasers, as users). They do NOT do enough to justify this insanity. There is zero justification to consider that of course one needs an obscenely powerful portable supercomputer for this task. There is zero justification to consider a 2019 Air "underpowered" for this task. "Mac M1 with 64GB of RAM and 10 CPU cores, everything feels lightweight"Īre insane sentiments to express, and it's an insane world that makes those thoughts seem agreeable to anyone. "I use an underpowered MacBook Air from around 2019" I assume I'll use emacs as long as I continue to use computers, and it's been decades since I thought editors really should be written in assembler, but this: Which would never happen due to elisp messiness. A better solution would have being having first class async and background threads support at the elisp level. I think, lsp-mode fork is doing the right thing (from practical POV it goes against "emacs is just an elisp interpreter" ideology though) and hope it gets into core at some point. So, heavy emacs users are building some async machinery which wraps another already async and relatively lightweight protocol, because core emacs facilities can't keep up with it. That's why we have lsp-bridge and lsp-mode emacs fork :) Both of which build some infrastructure to avoid doing communication work with lsp-mode work in main emacs thread. ![]() ![]() ![]() > For example, querying your compiler for a list of methods that apply to the current object, or a list of functions that start with “Foo” are mostly moving to external processes using LSP as the communication protocol. Practically, it is implemented as polling things on main thread with some witing happening in non-async fashion. When I am running a compilation (with output being dumped into a visible buffer) + query magit for large commit. I haven't used Visual Studio Code, but my understanding is that it is plenty responsive to typing and cursor movement, even while using rust-analyzer. But, even if my LSP server of choice is extremely slow, why should that affect my cursor movement or typing speed in my Emacs buffer? I can see why it would be technically difficult to make it NOT introduce some lag, but it shouldn't in principle. My understanding is that there are still bottlenecks in Emacs that make this not truly async. However, Emacs is also still kind of laggy when using LSP, even though the actual LSP server lives in another process and communicates mostly asynchronously. So, when some other IDE is using multiple GB of memory on my Rust project, we have to compare that to my Emacs + rust-analyzer memory usage because both of those processes are providing the features that other-IDE is providing. When it comes to memory, my point is precisely that we should count the language server in the total and not just the Emacs process. I'm using rust-analyzer as an example, but I also use other language servers and observe similar UI lags/stutters. ![]()
0 Comments
Leave a Reply. |