org-msg VS eglot

There is also org-msg as another option (haven't tried both so can't compare).

org-msg replaces a lot of message composition behavior, so it's not a big surprise that it doesn't respect that variable. Make sure you're referencing org-msg's README while customizing it.

Funny, just dealt with the whole O365 authentication just this week. With moving to 2 factor authentication you need to use OAuth 2 to do anything with it. I have my (work) O365 email forwarded, so I do have normal IMAP access. I use isync/mbsync [1] to receive email, goimapnotify [2] to get pushed new email, read/reply/etc with mu4e [3] and org-msg [4] and org-mode, and until recently just plain SMTP to send mail. This last part will break with 2 factor, but found oauth2ms [5] to set up the OAuth to work with O365 SMTP. The trick was to find the "tenet ID" from the Azure page of your organization and to use Thunderbird's credentials [6] (or another mail program, since I can't make new app registrations on Azure to have my own "application"). That should also allow you to use IMAP with OAuth 2 as well, but haven't done that since I still have the forwarding. (As usual, I think the Arch Wiki [7] covers most of this too.)

[1] http://isync.sourceforge.net/

[2] https://gitlab.com/shackra/goimapnotify

[3] https://www.djcbsoftware.nl/code/mu/mu4e.html

[4] https://github.com/jeremy-compostella/org-msg

[5] https://github.com/harishkrupo/oauth2ms

[6] https://hg.mozilla.org/comm-central/file/tip/mailnews/base/s...

[7] https://wiki.archlinux.org/title/Isync#Using_XOAUTH2

I'm using org-msg like this (great package btw, doesn't get enough attention if you ask me):

https://github.com/jeremy-compostella/org-msg/issues/1#issuecomment-426415584 is one of the things which pushed me towards org-msg.

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.)