Emacs 29.1 is going to be released in 2023 spring with built-in LSP support (Eglot)

[Tentative release schedule for Emacs 29.1](https://yhetil.org/emacs-devel/87pmflysdt.fsf@gnus.org/T/) [Re: Progress on merging Eglot?](https://yhetil.org/emacs-devel/87y1u9fdp4.fsf@gmail.com/T/#m021e40f54621e3fe08876c00cc589cbc43ebefec) And that Emacs 28.1 was just released earlier this year! Although I think Eglot won't be enabled by default. Praying that Tree Sitter will make it in time 🙏. Edit: thank you João Távora and other maintainers.

Eglot is... interesting. I love it except for one thing, it doesn't "really" work with flycheck. It's the only big problem I have with it since from my experience flycheck works better than flymake. I'd totally use eglot if the syntax-checking backend can be easily configured.

LSP is more hype than useful, especially if you have a lot of different projects with variying languages and version of languages, you need to setup different language-servers for every project.. The amount of time it takes to setup everything right is longer than to just grep for function definitions anyway

Although I use lsp-mode over eglot, latest flymake is better than flycheck for me: the created extra flycheck_* (or *_flycheck) file is annoying to deal with when grepping.

I'm at a loss to know where to start in disagreeing with this. It does so very much more than finding symbols within the project, and setup is usually trivial.

Which flycheck file do you mean? One of my problems is that I want the errors to be displayed in the echo area while sharing it with the display of what type the symbol under the cursor is

I want to like Eglot, but is so far behind lsp-mode that's almost unusable for me.

It's created by this [https://github.com/flycheck/flycheck/blob/b8f5bad487dafb942b577b571786e4495bd5a400/flycheck.el#L1416](https://github.com/flycheck/flycheck/blob/b8f5bad487dafb942b577b571786e4495bd5a400/flycheck.el#L1416) I can' t always reproduce this, but it's super annoying when grep catches the file.

Good news! How about `use-package`, will it be included in Emacs 29.1? Any news about it?

I prefer lsp-mode when possible, too, but a lightweight built-in alternative without adding a package archive and installing it undeniably nice to have anyway.

[deleted]

[deleted]

AFAIK not all of the lsp-mode contributors have assigned copyright to the FSF, which would make it impossible to add to Emacs. (I'm not sure whether they're trying to get that to happen or not. I thought not, but saw a comment some time back which suggested otherwise. It would be really nice if they were able to make this happen.) The author of eglot factored this in from the outset, so it was never a blocker.

In addition to what u/7890yuiop said - nobody actually wants `lsp-mode` in the core. Neither `lsp-mode` maintainers, nor the users. Do you really want a new release of `lsp-mode` each time emacs is released(6m+) or you want a fix after melpa kicks in(2-3h)?

Wait…the fsf requires a copyright transfer?

> the created extra flycheck_* (or *_flycheck) It can be disabled, yet tipically there's a good reason to have it. Perhaps it's easier to tell your grep (especially if you're using the Emacs command) to ignore flycheck_* globs?

Even if that was all it did, the improvement over that and etags is night and day.

Yes, [to sue for GPL violations](https://www.gnu.org/licenses/why-assign)

Huh… interesting… thanks so much for sharing!!!

If we can get deeper tree-sitter integration as well, I'll be super happy! Good news either way

I imagine it'll remain in GNU ELPA as well, with new ELPA releases available inbetween the Emacs releases. Similar to Tramp and various other packages which are part of Emacs OOTB (which is super convenient), but often have newer versions available if something requires a fix. Obviously at the point of installing from ELPA one could argue whether there were benefits to it being in core, but I think there are a number of those (and hopefully more so in the longer term if things stabilise). I do recall some of your earlier comments on how LSP is generally still in flux, though, so I wouldn't be surprised if there were ongoing reasons to prefer the ELPA version for a while to come.

Only thing I've noticed lsp-mode has that eglot doesn't is dap-mode. What have you found missing?

I've used both, and I didn't notice many differences. At the same time, I'm only using completion and code actions, so I may have missed some interesting features. Would you mind detailing a few things you like in LSP-mode?

Looking forward to all the eshell improvements, too. It'll be nice to actually pipe output directly from one process to the next one, without writing to an Emacs buffer in between.

By this point it would have been nice if flycheck would be integrated too or takes over. It seems much more advanced. I thought flycheck surpassed flymake.

Same case for Org-mode I think.

You have to do that anyway for each project.

So, I don't use lsp for much but to see function/types definitions. Take for example this simple rust code: ``` let mut file = File::create("does_not_exists.txt").unwrap_or_else(|why| { panic!("! {:?}", why); }); ``` with lsp-mode, if I put my cursor anywhere over `unwrap_or_else` I can see the whole function definition `pub fn unwrap_or_else<F>(self, op: F) -> T where F: FnOnce(E) -> T,`, also, if I put my cursor anywhere over `why` in the `panic!` macro call, I can also see it's definition `why: Error`. With Eglot the first case works only after going *inside* the function call (the cursor needs to be after the `(`), the second does not work at all. Similar things happen with C++ and that's why I don't use Eglot. Maybe I'm missing something in my config: ``` (after! eglot (setq eldoc-echo-area-use-multiline-p nil) (setq eglot-extend-to-xref t) (setq eglot-ignored-server-capabilities (quote (:documentFormattingProvider :documentRangeFormattingProvider))) (add-to-list 'eglot-server-programs `(rust-mode . ("rust-analyzer")) `(c-mode c++-mode . ("/usr/bin/clangd" "-j=4" "--malloc-trim" "--log=error" "--background-index" "--clang-tidy" "--cross-file-rename" "--completion-style=detailed" "--pch-storage=memory" "--header-insertion=never" "--header-insertion-decorators=0")))) ```

I added a comment to this thread about what I find lacking in Eglot, I have to admit, haven't used it much.

I added a comment to this thread about what I find lacking in Eglot, I have to admit, haven't used it much.

I agree, I don't see a reason why flymake is better than flycheck other than that it is built-in.

Tree-sitter support seconded. The current 3rd party system for tree-sitter (emacs-tree-sitter) is not so easily portable and moving pretty slowly. I love what Neovim has done with it and want more of that in Emacs

Have you tried it on Tramp? Lsp-mode sucks there where as eglot works flawlessly. This just one example where the eglot makes all the basic things right.

It's faster and doesn't disturb my screen as much as lsp. Also, eglot inside Emacs doesn't take away lsp from you? See flymake (inside) and flycheck (external).

I wish there were a clear comparison of Eglot vs lsp-mode somewhere, especially from a user level feature perspective. I know that Eglot is supposed to integrate better into core emacs features, whereas lsp-mode freely uses popular in Melpa packages. I know that lsp-mode typically does more intrusive pop up style stuff (which many people like). It’d be cool to see a configuration guide that compares each so it is easier to know whether one or the other is a better fit.

Not really, I don't use LSP over tramp.

Raise a feature request on the mailing list

There's also [leaf](https://github.com/conao3/leaf.el), which is a great alternative with plenty of useful additional keywords and syntactic sugar. Also, like eglot, it requires contributors to sign up for the fsf to make eventual addition to core easier.

[deleted]

That's largely up to u/jwiegley

The only downside of flymake is the lack of existing backends. But it is pretty straightforward to write one. I've been using my own with eslint for years now.

Awesome! I’ve been using Eglot and enjoying how simple it was to configure and use. So happy that it is making it into Emacs 29

Are you talking about before or after the flymake rewrite? My understanding is that flymake after its rewrite basically copied all the things that initially had made flycheck better.

It is being worked on. This is an old Blog but linking for context : https://archive.casouri.cat/note/2021/emacs-tree-sitter/index.html

I explained it in another comment in this thread but it's missing some small niceties like displaying the error message in the echo area. You can kinda get it to do this but it's kinda spammy then and doesn't go well with the feature of eglot that shows you the type of the symbol under the cursor in the echo area. I personally just want the choice which extension handles syntax checking. Some people like flymake some flycheck, why not let people choose? The author of eglot sadly does not think this way.

cmake can easily make compile-commands.json and for those projects setup is easy. For an old make-based project with lots of conditional nesting, I never did get lsp-mode all-the-way working.

Another alternative is [pkal/setup.el](https://git.sr.ht/~pkal/setup) which might be an easier option to have built-in.

Isn't that the case with flymake?

Isn't that point moot with LSP?

I hope this is all the more reason to improve eglot. I used eglot at first but I had a project configuration that I just couldn't get eglot to grok. Installed lsp-mode instead, after toggling a few switches it worked on my project just fine.

no not really, sadly.

I don't understand the significance of this. I thought ideally more things should be moved out, not taken into emacs core. What benefit does having eglot built in provide?

I wouldn't expect it. There's a lot in the air atm waiting on various mode maintainer responses, so it's looking quite doubtful in 29.

I'm curious, is it because some LSP interaction logic might require frequent changes, so the Emacs release schedule doesn't quite fit the purpose? And does `eglot` have (or not have) something that makes being tied to Emacs releases less of an issue?

Interesting, I stumbled upon this file for Emacs Lisp, but it was always getting deleted the next moment. And I've never seen it for lsp-mode & flycheck integration. Maybe it's an issue of a particular checker, or maybe my disk (SSD, indeed) is faster than yours

How is leaf better (or different) than use-package? The readme says that it is "cleaner and more predictable", but is it only more keywords?

I agree on functionality, but there are two things that make it so I can't use lsp-mode. First on large codebases lsp-mode slows the entire emacs instance down. Second, it's just broken with tramp. It randomly hangs the entire instance. Eglot has neither of these issues. Given that, I'd prefer if the features were added to eglot, since it's a simpler and seemingly more reliable codebase.

`eglot` is a lot more minimalist, so to speak. It's more focused around just getting the lsp to talk to emacs, where as `lsp-mode` is more focused on making all the new and shiny lsp-powered functionality egonomic, `eglot`, intentionally, lacks a lot of `lsp-mode`'s features. Different goals, different architecture.

LSP has become a *very* significant thing for programming IDEs in recent years (and for good reasons -- it abstracts out some powerful tooling concepts into a system which, at least in principle, can be leveraged by any text editor or IDE). Having eglot built in makes Emacs capable of leveraging it by default, which is a pretty big deal.

> I thought flycheck surpassed flymake. That was true in the past -- and so flymake was completely redesigned for Emacs 26 to fix that situation.

YMMV :) If we're *only* talking about finding symbol definitions, the only "night and day" difference I experienced between a tags file and a language server is the fact that the language server was more than 100 times slower indexing the (medium-large) project. If that's the only feature you need, tags can still be the perfect option. YMMV depending on circumstances and language features, of course -- LSP will be the better choice for some people, for sure.

You don't have to set up *language servers* for each project if you're not using language servers, though.

Hm I might check again but from what I see flycheck is still ahead. Honestly better merge some of the Flycheck code into Flymake then.

Nice! I'm looking forward to not needing master branch for pgtk, pixel-scroll-precision-mode, and more color support in eshell/shell.

[Good luck with that.](https://github.com/flycheck/flycheck/issues/323)

lsp-mode enables alot of features by default, however you can turn off all of the unnecessary things if you want. Then you will have similar minimalistic integration like eglot. Another thing is that lsp-mode supports semantics highlighting, which is better than tree-sitter for complex language like c/c++. Actually there're a few bugs in c/cpp tree-sitter that's the only solution is something like semantics highlighting of LSP.

I tried your example, and at first it appeared that eglot was dropping the ball. What appears to be happening is the server is just returning markdown documentation for those functions, without any signature information, so eglot defers to eldoc to display the documentation, or at least that's what appears to be happening. In any case you can see the information in the `*eldoc*` buffer, and the json in an `*EGLOT xxxx events*` buffer. To see something when you have your cursor in such places, you would have to get eldoc involved. I think this is a case of eglot being minimalist and making use of the existing emacs facilities. Whether this is good or not depends on your personality probably. Personally, I like minimalist, even though it sometimes takes a bit more work to accommodate.

There's been a discussion about this on emacs-devel. Long-story short: all we need is someone willing to volunteer the legwork to dot all the i's and cross all the t's (documentation, ChangeLog, add to build, normalize the files according to Emacs standards and create the PR, etc). I'm happy to help as a supporting engineer in this process, but I lack the time to undertake this project at the moment.

> it's looking quite doubtful in 29. Don't doubt it.

Please do enlighten me :D I'd love to be wrong here

In my opinion, lsp-mode's acceptance of shipping extra setup code for different languages / language servers works better (I have not been able to get Tailwind CSS's language server working with eglot, for example), but having Eglot built in is still amazing to see. It's like Flymake: I don't use it, but Emacs would be worse off without it built in. Looking forward to the Emacs 29 release.

lsp-mode mode tries to be comparable with vscode featurewise. In that sense, lsp-mode covers not only the protocol stuff but also the stuff that is not part of the spec in order to make the server work OOTB. Just to give you an example, lsp protocol has initialization options and they are server specific. In recent versions of a server, they had an initialization option that is now required and the server stopped working. This is technically fixable in users' configuration even if the defaults are broken but you won't have a good OOTB experience. One would say: lets keep these configurations out of the core and have them in a separate package just like nvim does. But then why have the main package in the core at all given the fact that either way you should install one more package?

https://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/tree-sitter There have been some recent updates, notably the addition of Python support.

Fwiw, I wrote a package to reuse flycheck backends with flymake: https://github.com/purcell/flymake-flycheck

Yeah, I was referring to https://yhetil.org/emacs-devel/3A68545C-2E40-4BB4-8563-8041A5452634@gmail.com/T/#u as waiting on responses

From my perspective, is faster than use-package. You get a noticeable speed up in Windows.

Really looking forward to Eglot being merged. I like its minimalist approach and easy setup.

Did you try `Bear`? We've got a fairly labrynthine ancient CMake (lots of compile-time code gen) which wasnt generating compile_commands.json right, but bear "just worked"

Thanks for the response! However, I already know what LSP is. I even use eglot myself. My question was more why it should be in by default. It's going to end up being an out of date version that needs updating anyway. For those who don't use LSP or use an alternative package such as `lsp-mode` it's just more bloat. What benefit is there to having it built in? Eglot is already in elpa. So this change makes it slightly quicker than `M-x package-install <ret> eglot <ret>`?

You know that you can use Eglot today and don't need to wait until it gets merged, right?

I mostly agree with you. I guess my definition of minimalism is different from yours (personality probably)

I think tree-sitter and leaf should be added to Emacs core as well! Tree-Sitter is fast and we could finally replace regex base syntax highlighting! Leaf is much lightweight and slightly faster than use-package (in Windows)!

True, eglot nails these things but lacks in the more common usecases for me

You know there will be a new set of desirable features popping up in master... It never ends (thankfully).

I 💕 eglot

lsp-mode is bloated

I use clangd (previously ccls) and fortran-language-server with a ~13 MLOC mixed C++/F77. Once the initial indexing is done, clangd is blazing fast. Between that and how frequent the churn of the C++ code is, I'll never go back to tags. (Even fls is "good enough".) And that's *only* for C++. I used to think "nah, I am faster at finding stuff in a Python codebase using an editor with no helpers over an IDE". I have no clue how well tags work for Python, but there's no need anymore, since pyright is almost as good as clangd. New language? Adding the language server is so easy. Maybe part of what you're saying is that the server is definitely an investment: those ecosystems that have prioritized tooling or have accumulated a lot of hours in it have excellent servers (C++/C, Python, Rust, ~Fortran) and those that haven't...the experience either adds nothing or is frustrating at best (CMake, Julia, Nim).

In my case, neither works on Tramp. LSP mode is still better - its straight up fails and does not block the UI. Eglot, on the other hand, blocks the UI until it tries to start the server (pyright in my case), sometimes for an entire 3-5 mins. Eglot is able to connect to the server eventually, but the UI becomes so laggy by then that completions are not instant, and the coding experience is severely degraded. I don't know how to make it faster in my use case, but I really don't like the long UI blocks offered by Eglot.

But you need to setup the build target for each project this includes tooling, lsp server's are part of the tooling.

We intend to include reasonably useful tree-sitter support in Emacs 29. You could guess that from the discussions on emacs-devel lately.

Why would Emacs users need to install packages to have what is nowadays considered to be basic IDE functionality? Would you agree to have Dired of `font-lock` or `compile` or `grep` only on ELPA? It makes no sense to have an Emacs that doesn't have the minimum set of features without which it can never be considered complete. Besides, having a package in core means it gets much more attention from the developers, which means better style and cleaner code, better documentation, better integration with other features, etc.

> Would you agree to have Dired of font-lock or compile or grep only on ELPA? Well, yes. Perhaps I have a distorted view of Emacs, but I've always seen an IDE as something Emacs has an option to be, not something it is. > better integration with other features Ah I didn't consider this.

Why it's faster than use-package on Windows?

I've no idea what you're saying, tbh. Language servers are 100% optional; there is no *need* to include them anywhere.

Tree-sitter support in core has been in the works for quite some time already. It's coming.

I think it's faster overall but it's more noticeable in Windows. The implementation is much more lightweight so you gain less load time. That's all.

> Do you really want a new release of lsp-mode each time emacs is released(6m+) or you want a fix after melpa kicks in(2-3h)? That doesn't make any sense. If lsp-mode were one of these core ELPA packages, it could have releases whenever it wanted. I suppose this is how its going to be for Eglot.

Then why do we need a version that will be broken after a few months in the core to confuse the users? And that will be for years ahead... I can tell you for sure that even if we put a banner in the readme "PLEASE DON'T USE THE VERSION FROM THE CORE BUT INSTALL THE LATEST ONE" we will still get tons of invalid bug reports.

Something else is broken. My eglot starts instantly btw even on Tramp. I am on WSL.

I may be getting the whole thing wrong, but I'd say if some package is in the core, it is the latest version by definition. I.e. you develop it there, make commits there, etc. But, if you were to say that managing packages from the core is tricky if you have lots of dependencies (which also need to go into the core), then I would understand.

Would it be correct to say `eglot` is more Emacs-like and `lsp-mode` is more like the LSP features of modern IDE?

https://www.reddit.com/r/emacs/comments/xmqhq2/comment/ipt9sfa/

I think so. However eglot lacks some useful features that could be implemented in an emacs-like way. Last I checked an example of this is "show call hierarchy".

Can you expand on this?

You can use eglot inside of vscode devcontainers because of this which makes being an emacs boat in a sea of vscode much easier.

leaf doesn't load packages by default. This is the same with setup.el. use-package loads packages that are not specified to be deferred, so naively written configurations are slow to start. I guess the difference is more noticeable on Windows because of slower IO performance.

Third tree sitter support would would be great as the 3rd party one is ehh

If you're on WSL, you may want to take a look at something like [`lsp-docker`](https://github.com/emacs-lsp/lsp-docker) which bypass all quirk of Tramp and works directly with your files in WSL. I've never been able to make Tramp work reliably (too much hanging with or without `lsp-mode`) from Windows -> WSL so bypassing it provides a much better experience. Here is an example of my config for WSL with lsp-mode that bypass Tramp ``` elisp (use-package lsp-wsl-clients :no-require t :after lsp-mode :config (require 'url-util) (defun lsp-wsl--uri->path (path-mappings on-windows? uri) (lsp--fix-path-casing (let* ((system-type (if on-windows? 'windows-nt 'wsl)) (path (lsp--uri-to-path-1 uri))) (-if-let ((local . remote) (-first (-lambda ((_ . remote-path)) (string-prefix-p remote-path path)) path-mappings)) (concat local (substring path (length remote))) uri)))) (defun lsp-wsl--path->uri (path-mappings on-windows? path) (let ((lsp--uri-file-prefix (if on-windows? "file:///" "file://"))) (-if-let ((local . remote) (-first (-lambda ((local-path . _)) (string-prefix-p local-path path)) path-mappings)) (concat lsp--uri-file-prefix (url-hexify-string (concat remote (substring path (length local))) lsp--url-path-allowed-chars)) (lsp--path-to-uri-1 path)))) (eval-and-compile (cl-defun lsp-wsl-register-client (&key server-id wsl-server-id path-mappings on-windows? wsl-dist-name priority server-command) (if-let ((client (copy-lsp--client (gethash server-id lsp-clients)))) (let* ((path-mappings `(,@path-mappings (,(format "//wsl$/%s/" wsl-dist-name) . "/")))) (when on-windows? (setq path-mappings (--map (cons (cdr it) (car it)) path-mappings))) (when priority (setf (lsp--client-priority client) priority)) (setf (lsp--client-server-id client) wsl-server-id (lsp--client-uri->path-fn client) (apply-partially #'lsp-wsl--uri->path path-mappings on-windows?) (lsp--client-path->uri-fn client) (apply-partially #'lsp-wsl--path->uri path-mappings on-windows?) (lsp--client-new-connection client) (lsp-stdio-connection server-command)) (lsp-register-client client)) (user-error "No such client %s" server-id)))) (with-eval-after-load 'lsp-rust (lsp-wsl-register-client :server-id 'rls :priority -3 :wsl-server-id 'rls-wsl :wsl-dist-name "Ubuntu" :server-command `("rls-wsl") :path-mappings '(("c:/" . "/mnt/c/") ("d:/" . "/mnt/d/"))) (lsp-wsl-register-client :server-id 'rust-analyzer :priority -2 :wsl-server-id 'rust-analyzer-win :on-windows? t :wsl-dist-name "Ubuntu" :server-command `("rust-analyzer.exe") :path-mappings '(("c:/" . "/mnt/c/") ("d:/" . "/mnt/d/")))) (with-eval-after-load 'lsp-go (lsp-wsl-register-client :server-id 'gopls :priority 0 :wsl-server-id 'gopls-wsl :wsl-dist-name "Ubuntu" :server-command `("gopls-wsl") :path-mappings '(("c:/" . "/mnt/c/") ("d:/" . "/mnt/d/"))))) ```

I think this is natural. Think about the vscode, vscode has its builtin LSP client, but you need to install plugins from their extension market to have LSP server work.

Yep, and also vscode is on a 1-month release cycle. If think more about that Emacs is like Electron(the platform), lsp-mode/flycheck/eldoc/etc is like VScode(the application/IDE) and lsp-java/lsp-dart/etc are like the plugins(the adaptors). I am much more about moving the stuff out of Emacs, than putting stuff in it. Why do I need 1500+ packages in emacs given the fact there is a package manager? ATM lsp-mode has a lot of issues caused by the fact that some packages are in the core, and not in elpa/melpa.

Hi, can you please share any config you use for eglot+tramp?

flycheck doesn't have a way to show all errors across all buffers; flymake does.

Yes. That’s what i am saying. :)

Hey, I don't have any configuration btw. Just M-x eglot. However, you need to make sure that the Pyright is detectable by eglot. So added the installation path to \`tramp-remote-path\`. I can share that if you need. (Optional ) I have the pyrightconfig.json file in each project. Note: My remote machines are standard ubuntu machines without any fancy shell/setup.

I think if you visit a project often enough the time investment to get everything working right with LSP might be worth it, that is not the case in my job, a simple grep command is usually sufficient enough

I don't follow you, I don't need to setup anything if I don't want to

Sure but if i want working tooling for each project you to setup that since language servers is part of tooling you have to set that up if you want it working. If you use an ide this part is done automatic unless you have embedded projects that use a different sysroot.

Emacs doesn't do .0 releases? E.g. 29.0?

If you have a lot of workers doing the same that setup time will be really costly, or if you have a lot of projects it is not feasible. The future is containerized development environments per project, like Gitpod.io where everything is installed on-demand, even the editor, LSP-servers and it's plugins are setup and you have a working editor in browser with support for multiple LSP-servers at the same time running. The setup time / cost per projects approaches zero

So basically lazy loading packages?

It relies on autoloads, so it's lazy loading.