Hacker News Reader

Comment by JacksonGariety | Hacker News Reader

The Emacs community should start by perfecting lsp-mode so that it can compete with VS Code in terms of functionality. That will simultaneously keep power users from switching AND bring in people from other "easy to use" editors that lack such functionality.

View on HN

I basically gave up on Emacs and switched to a combination of VS Code and old-school vi for Go and everything else, respectively. Finding an effing theme that allowed me to program in Go in a terminal without making LSP’s overlays unreadable was nearly impossible. I spent days trying to make this work. I’ve used Emacs since 1991.

This is possible, but it's a bit of a pain. One problem is that the popular themes cater to GUI Emacs users where you have 24-bit color depth. On the terminal this gets approximated to one of the available 256 colors, and this approximation is often not great. This makes themes on the terminal look weird sometimes.

With some work, you can enable 24-bit color support in TTY emacs, which solves this problem. Combine this with some work to either tweak or remove the more obnoxious LSP overlays and you can have a fairly good LSP experience on the TTY.

I wanted a monochrome terminal but was willing to tolerate traditional ANSI color. Once you start with 24 bit color you may as well start using a VNC client.

What sapped my will to live was the impossibility of doing a C-u C-x = on the overlays to determine how their contents were styled, forcing me to go into the source code of a ton of different packages to go fishing for face names to coerce to visible values.

Yes it’s possible but it’s insane. Emacs carries around all of this terminal baggage but many module developers seem to have forgotten about terminal users. Additionally, theming is conceptually broken in that it creates an MxN problem with themes and modes’ face names. This could be solved if modes stopped with the proliferation of mode-specific face names but good luck with that.

Emacs needs this so bad but I really believe it could never attract enough people to develop and maintain it without sane defaults.

I find that lsp-mode works pretty well most of the time. If you look at the commit history, the project is very active. It's also pretty easy to set up.

I found that it didn't work out of the box for me (Rust and Python) but that eglot did work out of the box.

Eglot, not lsp-mode, will be the LSP implementation that makes it into the GNU Emacs distribution (because it is being developed with FSF assignments, and because the maintainer is active in the GNU Emacs development community, maintaining eldoc and flymake, and maybe others).

It would be bad if it did, IMO. Eglot is a pretty dodgy piece of software and the code is much worse than lsp-mode.

Could you give some justification for that criticism and assertion please? (On its own, your comment falls short of HN standards.)

Sure, here are some samples from the source.

This is Eglot's code. Try and figure out what's happening in each of these passages:

https://github.com/joaotavora/eglot/blob/master/eglot.el#L41...

https://github.com/joaotavora/eglot/blob/master/eglot.el#L17...

Contrast with lsp-mode:

https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-mode.e...

https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-modeli...

The lsp-mode code is a lot easier to follow, in my opinion. It's a lot clearer what's happening (although I can't say much about whether either are overabstracted which is admittedly a big concern. I haven't looked into that).

I remember watching an argument between the original authors on Reddit a while back. The lsp-mode author came across as... let's just say more professional. lsp-mode seems much closer to a professional product to me in general.

Thanks. It's true that the eglot code is hard to understand (and based on your links I suspecter hard_er_). I had been provisionally assuming that that was because the author is a much more advanced lisp programmer than me (which is true; I'm fairly sure he's one of those emacs developers that is also an experienced common lisp developer).

In any case, I would prefer that neither become part of GNU Emacs since then the development process and code review will become completely opaque (I'm not sure code review is really a thing once it's in Emacs. Just maintainers with push rights to some repo on savannah or something)

Also it's low resolution, but note the issues ratio.

Eglot: 70 open, 277 closed

lsp-mode: 94 open, 977 closed

(lsp-mode is much more than 3x the size of eglot and has 15x the number of downloads on MELPA)

Is the LSP architecture the way to go, though? In my experience it's quite a bit slower than built in emacs modes. I can't use tools that are slower than me.

Maybe, but at the same time it seems like the best option for general language support in emacs.

A lot of languages have working lsp implementations (at least according to https://langserver.org/) and, assuming it will stick around, this means that emacs can get all of these nice features "for free" by having an lsp implementation. This is a much safer bet than just assuming that somebody will provide and maintain emacs plugins for <insert language x here> that provide everything that lsp would.

Are you on Emacs 27 yet? Below that Emacs encodes JSON in Elisp, which is extremely slow and makes LSP unusable.

Upgrading to 27 made no difference for me.

In that case something dramatic is eclipsing it, it should be noticeable. It may be the GC threshold. There's about 5 settings recommended for perf issues.

https://emacs-lsp.github.io/lsp-mode/page/performance/

Ordinarily I'd ignore rabbit holes like this but LSP is unusually useful. It's worth a shot.

I've done all of that. Still slow. I think the problem is other people have lower standards than I do when it comes to speed.

There's a command called M-x lsp-doctor that will tell you if you meet all the performance requirements for LSP mode. Among those is emacs 27 compiled with native json support (you can build emacs 27 without native json).

Reply on news.ycombinator.com