5 ms·

Its great to see both eglot and tree-sitter being merged. However, I am unhappy about the state of 'emacs configurations/distributions' right now. I have been u

Its great to see both eglot and tree-sitter being merged. However, I am unhappy about the state of 'emacs configurations/distributions' right now. I have been using Doom Emacs, but the development is pretty much stalled there [0], and I don't think there is any distribution that is keeping up with these cutting-edge features (compared to the NeoVim ecosystem, let's say). Somehow it feels like I was seeing a lot more activity about Emacs configurations two-three years ago. > Compile EmacsLisp files ahead of time Ooh, this is interesting. Hoping to see a derivation in https://github.com/nix-community/emacs-overlay https://github.com/nix-community/emacs-overlay soon. [0] I am not complaining though as Doom was the main author's personal config from the get-go. I am just pointing out a void.

YetAnotherNick 4y ago
It's definitely not stalled by any metric: https://github.com/doomemacs/doomemacs/commits/master https://github.com/doomemacs/doomemacs/commits/master
- e3bc54b2 4y ago
  It is not stalled, but as it currently stands, Henrik is bottleneck. He used to work like a fiend, but obviously its not sustainable for one guy to keep carrying on for something with as large scope as an Emacs distribution. There are plans to split doom-emacs' core and contrib modules in separate modules, but no idea what the progress is on that.
- yewenjie 4y ago
  I would argue very few of those commits are feature commits of late. Once again, I am deeply thankful to Doom Emacs, and in no way 'demanding' anything from the project.
  - smsx 4y ago
    Actually, in the last few months there has been an absolute ton of feature work. A very sophisticated generational profile system was introduced, and the entire framework is being split into separate packages to enable more stable versioning. This is all with the goal of reducing the bus-factor from being just Henrik.
jacobsenscott 4y ago
I don't know if doom or other sort of meta-emacs distributions are as useful as they were a few years ago. Good package management is baked in to vanilla emacs now, and most any package can be configured without writing a line of elisp with the M-x customize-group. I recently went from a whole subdirectory of configuration files to the single default init.el and have been very happy with it. I am still using `use-package` for some packages, but I don't really find it any better than just M-x package-install and M-x customize group. In fact I would encourage new emacs users not to use some any meta-distribution or third party package management - none of them will live as long as emacs (which will live forever).
bigpeopleareold 4y ago
I tried Prelude and Doom. After some time with Doom, I switched back to Prelude. Doom was too buggy for me. While it is not really a problem with Doom (in that I can configure it myself), the idea of using Doom ended when the default selections for Python-LSP were awful (wanted to just use Jedi, but it only had the Microsoft one, which at the time, had a horrible memory leak.) My old Prelude setup covered exactly what I needed.
truncate 4y ago
As a lsp-mode users, why switch to eglot?
- NoGravitas 4y ago
  If you're happy with lsp-mode, there's not much reason to switch. The main thing about eglot is that it's less-intrusive. It doesn't make any UI changes (unlike lsp-ui), and doesn't even install a keymap by default. But it hooks into Emacs' existing facilities (like xref and completion-at-point) and lets them use an lsp-powered backend. There are functions for things that don't already have an equivalent (like refactorings or code actions), but they're not bound.
  - anyfoo 4y ago
    > like xref and completion-at-point Where does that persistence myth come from that lsp does not hook into that? Maybe it once did not, but I've been using lsp for at least a couple of years now and I do not remember it not using xref. Not so sure about completion-at-point, haven't checked because my completions work as they should using company.
- srcreigh 4y ago
  Never used LSP. Imo eglot is a test for your knowledge of other good packages. It won’t work nicely without turning on company-mode, flycheck-project-buffer (spelling?) etc. But it’s good to know about those anyway. LSP to me always seemed like a all-in-one don’t have to think of know what’s going on type of package. Depends what you want. I’ve found eglot to be hackable too. I had ugly Horizontal Rule in eldoc for rust code due to tamsyn font. Well eglot->eldoc-> some builtin markdown package -> finally discovered a config option for the character used to draw hr’s. On one hand it’s annoying to go 3 dependencies deep to configure eglot behaviour. But emacs makes that kinda thing accessible (if not easy) and I learned something.
- ParetoOptimal 4y ago
  Using lsp within devcontainers/docker containers via tramp.
tikhonj 4y ago
I've been using Emacs overlay to compile packages ahead of time for a while. Unless I've misunderstood how it works, that's what the variations on emacsWithPackages do. I use the version of emacsWithPackages that parses use-package declarations from my .emacs file and uses Nix to compile and install the corresponding Emacs packages. The upside is that this also pulls in native dependencies (pdf-tools/etc) but the downside is that adding a new package requires rebuilding at the Nix level and restarting Emacs. It has not been a major problem for me—I don't install new Emacs packages very often at this point—but I can definitely see how it could get annoying for anyone who does!
- tadfisher 4y ago
  While not in line with the Lisp philosophy, it's far more hygienic to restart Emacs after a configuration change rather than reloading the init file. There's really no way to bring Emacs back to a pre-init state in order to recreate the initialization process. Not to mention that compiling the init file runs different code than loading the init file, and Lisp expressions are far from idempotent, so you can't really be sure your changes work until you restart Emacs anyway.
- theCodeStig 4y ago
  This echos my set up, and it's quite stable, particularly if the overlay is pinned.

YetAnotherNick 4y ago

It's definitely not stalled by any metric: https://github.com/doomemacs/doomemacs/commits/master https://github.com/doomemacs/doomemacs/commits/master

e3bc54b2 4y ago
It is not stalled, but as it currently stands, Henrik is bottleneck. He used to work like a fiend, but obviously its not sustainable for one guy to keep carrying on for something with as large scope as an Emacs distribution. There are plans to split doom-emacs' core and contrib modules in separate modules, but no idea what the progress is on that.
yewenjie 4y ago
I would argue very few of those commits are feature commits of late. Once again, I am deeply thankful to Doom Emacs, and in no way 'demanding' anything from the project.
- smsx 4y ago
  Actually, in the last few months there has been an absolute ton of feature work. A very sophisticated generational profile system was introduced, and the entire framework is being split into separate packages to enable more stable versioning. This is all with the goal of reducing the bus-factor from being just Henrik.

jacobsenscott 4y ago

I don't know if doom or other sort of meta-emacs distributions are as useful as they were a few years ago. Good package management is baked in to vanilla emacs now, and most any package can be configured without writing a line of elisp with the M-x customize-group. I recently went from a whole subdirectory of configuration files to the single default init.el and have been very happy with it. I am still using `use-package` for some packages, but I don't really find it any better than just M-x package-install and M-x customize group. In fact I would encourage new emacs users not to use some any meta-distribution or third party package management - none of them will live as long as emacs (which will live forever).

bigpeopleareold 4y ago

I tried Prelude and Doom. After some time with Doom, I switched back to Prelude. Doom was too buggy for me. While it is not really a problem with Doom (in that I can configure it myself), the idea of using Doom ended when the default selections for Python-LSP were awful (wanted to just use Jedi, but it only had the Microsoft one, which at the time, had a horrible memory leak.) My old Prelude setup covered exactly what I needed.

truncate 4y ago

As a lsp-mode users, why switch to eglot?

NoGravitas 4y ago
If you're happy with lsp-mode, there's not much reason to switch. The main thing about eglot is that it's less-intrusive. It doesn't make any UI changes (unlike lsp-ui), and doesn't even install a keymap by default. But it hooks into Emacs' existing facilities (like xref and completion-at-point) and lets them use an lsp-powered backend. There are functions for things that don't already have an equivalent (like refactorings or code actions), but they're not bound.
- anyfoo 4y ago
  > like xref and completion-at-point Where does that persistence myth come from that lsp does not hook into that? Maybe it once did not, but I've been using lsp for at least a couple of years now and I do not remember it not using xref. Not so sure about completion-at-point, haven't checked because my completions work as they should using company.
srcreigh 4y ago
Never used LSP. Imo eglot is a test for your knowledge of other good packages. It won’t work nicely without turning on company-mode, flycheck-project-buffer (spelling?) etc. But it’s good to know about those anyway. LSP to me always seemed like a all-in-one don’t have to think of know what’s going on type of package. Depends what you want. I’ve found eglot to be hackable too. I had ugly Horizontal Rule in eldoc for rust code due to tamsyn font. Well eglot->eldoc-> some builtin markdown package -> finally discovered a config option for the character used to draw hr’s. On one hand it’s annoying to go 3 dependencies deep to configure eglot behaviour. But emacs makes that kinda thing accessible (if not easy) and I learned something.
ParetoOptimal 4y ago
Using lsp within devcontainers/docker containers via tramp.

tikhonj 4y ago

I've been using Emacs overlay to compile packages ahead of time for a while. Unless I've misunderstood how it works, that's what the variations on emacsWithPackages do. I use the version of emacsWithPackages that parses use-package declarations from my .emacs file and uses Nix to compile and install the corresponding Emacs packages. The upside is that this also pulls in native dependencies (pdf-tools/etc) but the downside is that adding a new package requires rebuilding at the Nix level and restarting Emacs. It has not been a major problem for me—I don't install new Emacs packages very often at this point—but I can definitely see how it could get annoying for anyone who does!

tadfisher 4y ago
While not in line with the Lisp philosophy, it's far more hygienic to restart Emacs after a configuration change rather than reloading the init file. There's really no way to bring Emacs back to a pre-init state in order to recreate the initialization process. Not to mention that compiling the init file runs different code than loading the init file, and Lisp expressions are far from idempotent, so you can't really be sure your changes work until you restart Emacs anyway.
theCodeStig 4y ago
This echos my set up, and it's quite stable, particularly if the overlay is pinned.