.emacs.d VS eglot

If you want to dip your toes, I'd maybe try out https://github.com/doomemacs/doomemacs if you like vi style keybindings or https://github.com/seagle0128/.emacs.d or if you want to use something more traditional. Then I'd recommend https://github.com/gcv/julia-snail for the julia side of things.

Do not use doom as the heretics suggest! It is an awful experience and very janky, they also change how emacs is configured in a weird way that doesn't lead to one understanding the lisp or how emacs starts up. I'd suggest witchmacs (https://github.com/snackon/Witchmacs) or centaur emacs (https://github.com/seagle0128/.emacs.d) to get a feel of how a config actually looks like. With doom it is obscured under so much. As an exvimmer I moved to god-mode and emacs bindings just because everything always works with these. Using evil gets a little complicated since it doesn't always function properly. But using evil is probably best for you at the moment.

My favourite emacs starter kit is centaur emacs, it makes great use of hydras and improves on the standard key bindings. But I have to say I love the look of NΛNO and the svg-lib. u/Nicolas-Rougier, have you thought about combining some of the features of centaur with your work?

If you are looking for an alternative to doom without evil mode, I recommend centaur emacs. https://github.com/seagle0128/.emacs.d

To me, Vanilla Emacs config certainly. I create Centaur Emacs for myself and share to others.

There is https://github.com/seagle0128/.emacs.d and there is my own distro https://github.com/Ultra-Hax/magmamacs which is more minimal but less customizable and more opinionated both of these distros are very minimal and blazing fast.

Example configuration - https://github.com/seagle0128/.emacs.d/blob/e225dbe431f1e7ad368f3fe11d63ceb60c5acfcb/lisp/init-window.el#L142

Recently I stumbled upon this issue:

https://github.com/joaotavora/eglot/discussions/1127

I don't know enough about emacs and LSP to see the full picture, but it seems that both eglot's and corfu's maintainers, assumably very competent programmers, can't find a solution for this.

I only skimmed the thread. My understanding is that LSP dumps a long list of completion candidates at once and they can't decide a cache strategy that works well with existing code...?

It could be. There are unfixed issues with eglot and corfu, and sadly not a lot of willingness to investigate.

Eglot errors when I add new Python code blocks. The error disappears when I reconnect the language server, but the same happens again when I add a new code block. My "workaround" now is that before I start working on the .qmd file, I just add a bunch of Python code blocks (for which I also have a function) and then reconnect the language server again. This way I can start working for a while until I need to add more code blocks again.

This discussion has helped with some performance issues: https://github.com/joaotavora/eglot/discussions/993.

I guess eglot doesn't support it yet: https://github.com/joaotavora/eglot/pull/839

This is not by pure chance, João is the developer of the Eglot LSP client and the breadcrumbs from LSP-mode had been requested as a feature, but as far as I remember João thought rightfully that this could be an independent package, see https://github.com/joaotavora/eglot/discussions/988

A substantial section of the community is using corfu instead of company, but I wouldn't say company is out of date by any means. In emacs 29 eglot will be a built in, which might act as a replacement for lsp-mode depending on what functionality you need.

I am currently running emacs 29 (built from emacs-29 branch) which – according to https://github.com/joaotavora/eglot – should contain the latest eglot.

Yep. You can use flymake or flycheck for that in combination with eglot or lsp-mode.

See https://github.com/joaotavora/eglot#diagnostics

(I have reported this (that is, ElDoc missing docs for callable things at point, when Eglot is enabled) as an issue recently: First on GitHub-discussions https://github.com/joaotavora/eglot/discussions/1200, then on Debbugs https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62687. But the threads are very long, so I don't recommend reading them.)