IMHO it’s very exciting to see how Emacs is getting modernized without loosing its ethos.
package.el added a lot of dynamism to the community. Without package management, it was very cumbersome to install things, track dependencies and keep them up to date.
use-package is now more or less a de facto standard for package configuration, and I think merging it into Emacs would bring lots of benefits (spoiler, it seems it might happen [1]).
The end goal should be make it possible to run a modern Emacs with plenty of features yet a tiny .emacs or init.el.
my biggest problem with use-package is that it hides away a lot of the implementation details, which I think is a barrier between being a user and a programmer of emacs.
Of course it’s (e)lisp, so you can do the same with the built in macro expansion facilities and introspection, with finer control. This package makes it trivial to explore macros.
Love macrostep! Tho the problem I have with use-package is also that it expands to pretty (imo over-) complicated code. I prefer a package like setup.el or even my own thing I’m playing around with that’s more of a progn around a related block of configurations.
I agree that packages are great, and that keeping related stuff together in a toplevel form is good. I just don’t like how use-package does it, I think … like I prefer pkal’s setup.el (see my comment above for a link) or more transparent idioms….
I almost feel like use-package is a packaging equivalent to cl-loop, with its own DSL you have to learn.
I guess the main thing for me is I never saw the problem with the old style that use-package is meant to replace. Maybe back before with-eval-after-load existed, granted the old eval-after-load was clunky, but there’s no reason to use that nowadays.
The use-package style is a little more concise but not enough to justify installing a 3rd-party dependency, at least for me.
If you put that directly in the top level it would error out when it was first evaluated because fennel-mode-hook isn’t a list. Previously you would have done:
The one thing I don’t like about use-package (although I do use it myself) is that, if you use its conveniences like :bind, :hook, etc, it becomes more awkward to just eval config changes, without doing the entire use-package form. I’ve moved to doing everything in :config; I miss out on a bunch of the nice features, but I greatly value the ability to incrementally change config stuff with ease.
Eglot is one of the best packages of Emacs. I’m still quite new to Emacs. When I started, I wanted to use some things other common IDEs provide (VS Code, PyCharm, …). The first suggestion you usually find is lsp-mode, which supports many things. But it was very complex, with lots of subpackages. Also, it didn’t work very well in the end. Then I started using Eglot. It was way easier to configure from scratch, contains a lot of languages by default, and seems less clunky.
I really like the stance of working with Emacs core infrastructure, rather than using Emacs just for rendering custom UI. I hope that this goes both ways, and Emacs core infra morphs more towards what we now know to be the best way to expose semantic info about the program to the user.
Some of the huge, obvious things off the top of my head:
completion infra: there shouldn’t be a need for an external completion framework, only for extra completion sources
navigate to any symbol in the project by interatively narrowing the search with fuzzy matching. I think something from xref should do this, but 10 minutes of googling was not enough to find that, and I have a vague recollection that the way it works is that emacs expects to have a full list of symbols, with client-side filtering, while what is needed is server side-filtering, where the client sends every new search letter to the server
imenu: this I think is mostly right abstraction already, but it, by default, should display the full tree of symbols in file
extend selection! That is, progressively extending selection to encompassing expressions. AFAIR, there’s no such thing in stock emach, but there
EDIT: forgot another huge one, code actions (the 💡 which is shown when the cursor is on the thing where some refactor is available). That’s a hugely important interface metaphor.
With Eglot you can use xref-find-apropos (C-M-.) which will let you search project symbols through LSP. Should have support for iterative completion, fuzzyness can be controlled by completion settings in Emacs (fuzzy completion is not enabled by default).
Yeah, that’s the thing: xref-find-apropos out-of-the-box requires to type the full query string up-front – it works for finding stuff you already know the name of, not for discovering things.
From what I could tell after briefly trying both, lsp-mode tries to give you a very full-featured IDE or VS Code-like experience. It’s got a lot of power and gives a fairly slick interface to it all with a good bit of bling. It seems to have a lot of code and a lot of dependencies.
Eglot on the other hand tries to be lighter weight. It’s a single .el file of about 3500 lines and it mostly just depends on a handful of built-in libraries. It’s philosophy seems to be more about blending in with the traditional Emacs experience, setting some stuff up and then mostly staying out of the way until invoked.
As a long-time Emacs user, I found Eglot much more to my taste and went with it over lsp-mode, but there’s definitely room in the ecosystem for both. I don’t use golang, so I can’t speak to that. It does come with an entry for gopls for go-mode in its list of known servers.
I’m hoping that we’ll see some packages bring some of the lsp-mode UI to eglot for those that prefer that style. I’ll be sticking with the vanilla eglot myself.
I am new to emacs but does treesitter work as an alternative for eglot? I am using treesitter and seems to be working fine for me, will using eglot+treesitter give me any extra bells? or these two are supposed to be mutually exclusive?
They are generally meant to compliment each other. Tree-sitter helps with syntax highlighting (font-locking) and structural navigation/editing. LSP generally knows more about your code, but it is too heavy/slow to be used for the tasks that tree-sitter is good at. It will offer autocompletion of functions, methods, parameters, and arguments, as well as some linting capabilities. It will also allow renaming of symbols and other more complex refactoring.
I would really like to like eglot. I like the fact that it’s lighter than lsp-mode, and tries to adhere more closely to Emacs interface conventions. Unfortunately, I have never gotten it working correctly with the OmniSharp language server for C#, even with manual setup. It works out of the box with lsp-mode, which will even install the latest version for you. So what I’ve been doing is using lsp-mode without lsp-ui, and with non-automatic completions.
I’m really looking forward to this being available out of the box for users. Even as a package, eglot is much more simple to use than neovim’s built-in LSP. If you’ve got a compatible language server installed, you just enable eglot mode and it works. No more config needed.
It is going to be even easier as a built-in package. At some point, language modes might start activating it automatically for you which will be an even better experience. It also means that the language modes might be able to simplify a bit and off-load more of the work to the language server.
For most folks, you would probably want to install an overlay style auto-complete package like corfu or company-mode to get the auto-complete style that they are used to in most other editors.
IMHO it’s very exciting to see how Emacs is getting modernized without loosing its ethos.
package.eladded a lot of dynamism to the community. Without package management, it was very cumbersome to install things, track dependencies and keep them up to date.use-packageis now more or less a de facto standard for package configuration, and I think merging it into Emacs would bring lots of benefits (spoiler, it seems it might happen [1]).The end goal should be make it possible to run a modern Emacs with plenty of features yet a tiny
.emacsorinit.el.[1] https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg01690.html
my biggest problem with use-package is that it hides away a lot of the implementation details, which I think is a barrier between being a user and a programmer of emacs.
I found the macrostep package incredibly helpful to understand what use-package was doing and to help track down issues.
Of course it’s (e)lisp, so you can do the same with the built in macro expansion facilities and introspection, with finer control. This package makes it trivial to explore macros.
Love macrostep! Tho the problem I have with
use-packageis also that it expands to pretty (imo over-) complicated code. I prefer a package like setup.el or even my own thing I’m playing around with that’s more of aprognaround a related block of configurations.In what sense? I find it very neat to standardize trivial things and avoid cluttering my configuration. E.g.:
One can always default to plain Elisp. Before
package.elanduse-package, it was hard to maintain complex configurations.I agree that packages are great, and that keeping related stuff together in a toplevel form is good. I just don’t like how
use-packagedoes it, I think … like I prefer pkal’s setup.el (see my comment above for a link) or more transparent idioms….I almost feel like
use-packageis a packaging equivalent tocl-loop, with its own DSL you have to learn.I guess the main thing for me is I never saw the problem with the old style that use-package is meant to replace. Maybe back before
with-eval-after-loadexisted, granted the oldeval-after-loadwas clunky, but there’s no reason to use that nowadays.The use-package style is a little more concise but not enough to justify installing a 3rd-party dependency, at least for me.
I’m curious, how do you use
with-eval-after-load? I got started withuse-package, so not really familiar with thecorefacilities unfortunately.Well, for example:
If you put that directly in the top level it would error out when it was first evaluated because
fennel-mode-hookisn’t a list. Previously you would have done:…which is fine in this example because there’s only one form but often you have to toss a
prognin there for nontrivial examples and it looks ugly.Thanks! Looks pretty reasonable for most of my configs.
The one thing I don’t like about
use-package(although I do use it myself) is that, if you use its conveniences like:bind,:hook, etc, it becomes more awkward to just eval config changes, without doing the entireuse-packageform. I’ve moved to doing everything in:config; I miss out on a bunch of the nice features, but I greatly value the ability to incrementally change config stuff with ease.Eglot is one of the best packages of Emacs. I’m still quite new to Emacs. When I started, I wanted to use some things other common IDEs provide (VS Code, PyCharm, …). The first suggestion you usually find is lsp-mode, which supports many things. But it was very complex, with lots of subpackages. Also, it didn’t work very well in the end. Then I started using Eglot. It was way easier to configure from scratch, contains a lot of languages by default, and seems less clunky.
I really like the stance of working with Emacs core infrastructure, rather than using Emacs just for rendering custom UI. I hope that this goes both ways, and Emacs core infra morphs more towards what we now know to be the best way to expose semantic info about the program to the user.
Some of the huge, obvious things off the top of my head:
EDIT: forgot another huge one, code actions (the 💡 which is shown when the cursor is on the thing where some refactor is available). That’s a hugely important interface metaphor.
With Eglot you can use xref-find-apropos (C-M-.) which will let you search project symbols through LSP. Should have support for iterative completion, fuzzyness can be controlled by completion settings in Emacs (fuzzy completion is not enabled by default).
Yeah, that’s the thing:
xref-find-aproposout-of-the-box requires to type the full query string up-front – it works for finding stuff you already know the name of, not for discovering things.Is Eglot better than
lsp-mode? How painful is the switch, for golang?From what I could tell after briefly trying both, lsp-mode tries to give you a very full-featured IDE or VS Code-like experience. It’s got a lot of power and gives a fairly slick interface to it all with a good bit of bling. It seems to have a lot of code and a lot of dependencies.
Eglot on the other hand tries to be lighter weight. It’s a single .el file of about 3500 lines and it mostly just depends on a handful of built-in libraries. It’s philosophy seems to be more about blending in with the traditional Emacs experience, setting some stuff up and then mostly staying out of the way until invoked.
As a long-time Emacs user, I found Eglot much more to my taste and went with it over lsp-mode, but there’s definitely room in the ecosystem for both. I don’t use golang, so I can’t speak to that. It does come with an entry for gopls for go-mode in its list of known servers.
I’m hoping that we’ll see some packages bring some of the lsp-mode UI to eglot for those that prefer that style. I’ll be sticking with the vanilla eglot myself.
I am new to emacs but does treesitter work as an alternative for eglot? I am using treesitter and seems to be working fine for me, will using eglot+treesitter give me any extra bells? or these two are supposed to be mutually exclusive?
They are generally meant to compliment each other. Tree-sitter helps with syntax highlighting (font-locking) and structural navigation/editing. LSP generally knows more about your code, but it is too heavy/slow to be used for the tasks that tree-sitter is good at. It will offer autocompletion of functions, methods, parameters, and arguments, as well as some linting capabilities. It will also allow renaming of symbols and other more complex refactoring.
I would really like to like eglot. I like the fact that it’s lighter than lsp-mode, and tries to adhere more closely to Emacs interface conventions. Unfortunately, I have never gotten it working correctly with the OmniSharp language server for C#, even with manual setup. It works out of the box with lsp-mode, which will even install the latest version for you. So what I’ve been doing is using lsp-mode without lsp-ui, and with non-automatic completions.
I’m really looking forward to this being available out of the box for users. Even as a package, eglot is much more simple to use than neovim’s built-in LSP. If you’ve got a compatible language server installed, you just enable eglot mode and it works. No more config needed.
It is going to be even easier as a built-in package. At some point, language modes might start activating it automatically for you which will be an even better experience. It also means that the language modes might be able to simplify a bit and off-load more of the work to the language server.
For most folks, you would probably want to install an overlay style auto-complete package like corfu or company-mode to get the auto-complete style that they are used to in most other editors.