Hmm, I've just remembered there's yet another alternative which is to use (eval-after-load 'desktop ...) in eglot.el. This wouldn't have the drawback of "load desktop.el inadvertently". Then again, eval-after-load shouldn't be used in packages, so I've read somewhere (manual?). Just mentioning this for completeness sake. João On Wed, Jul 6, 2022 at 2:19 PM João Távora wrote: > On Wed, Jul 6, 2022 at 2:12 PM Eli Zaretskii wrote: > >> > From: João Távora >> > Date: Wed, 6 Jul 2022 13:59:51 +0100 >> > Cc: 56407@debbugs.gnu.org >> > >> > That's okay: it's desktop.el's job to know about some implementation >> > details. Just look at how much it knows about what the various modes >> > and variables do in Emacs. >> > >> > Wait, you're saying it's "okay" to have to do a commit to Emacs's repo >> > everytime someone makes a third-party package that has a minor mode >> > that needs special handling? Or everytime someone changes the name >> > or shape of a minor mode? >> >> eglot is not a third-party package. We intended to add it to core, I >> think? >> > > Indeed we do. But it's not yet, because I've been so very busy. > > But if what I suggest isn't to your liking, you can always tell users > >> to customize desktop-minor-mode-table by themselves. Or do what you >> didn't want to do: cause desktop.el to be autoloaded by eglot. >> > > Yes, those are alternatives. But not as good. > > >> > But we do have that mechanism. It's called symbol properties and it's a >> nice >> > feature of lisp. So let's use it, please. >> >> If you insist. But then don't come back crying when this is broken by >> some change in desktop.el that the "loosely coupled packages" didn't >> pick up. >> > > Thanks. I can't vouch for my future emotions, but I also can't see how > this mechanism, which I've used and seen used so often, could fail > in such ways. > > I'll prepare a patch. > > João > -- João Távora