bug#56407: 29.0.50; desktop.el shouldn't be saving/restoring eglot--managed-mode, which is not for interactive use

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 6 Jul 2022 09:12:39 +0100
> Cc: 56407@debbugs.gnu.org
> 
>  I see no reason to require: you just add a value to the list, that's
>  all.
> 
> Oh, it's an autoloaded variable.  OK then, it'll work. It'll load in desktop.el 
> though.

I feel there's some misunderstanding here.  What I meant is simply add
eglot--managed-mode to the default value of the variable in
desktop.el.  Why would that require loading desktop.el?

>  > I think I like Lars's solution best.
> 
>  I don't: it makes the information spread out and harder to find.
> 
> Depends on whether one thinks using the global symbol table in Elisp is
> counts as "spread out". I don't.

What do you mean by "global symbol table"?

What I meant is that having all the modes which desktop.el treats
specially in one place in desktop.el makes it easier to find out which
modes are those, than if each of the modes had something like
"(put foo-mode 'desktop...)" in its own file.  Because in the latter
case, if I want to know which modes are handled specially by desktop,
I'd need to search the entire tree.

> There's a nice upside to it, which is it prevents people like me not 
> interested in desktop.el at all from having it autoloaded just by loading
>  eglot.el.  The things eglot.el is trying to say to desktop.el is "stay out of
> my minor mode" so it is strange that it has to pull in desktop.el every time
> just to say that.

See above: I don't think I understand why would you need to load
desktop.el.  The variable desktop-minor-mode-table is of interest only
when the desktop is saved or restored, and at that time desktop.el is
already loaded, of course.  No other code anywhere else should need to
consult desktop-minor-mode-table.  Or what am I missing?