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 12:30:28 +0100
> Cc: 56407@debbugs.gnu.org
> 
>  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?
> 
> Indeed, I misunderstood. I thought you meant adding that to eglot.el.
> 
> But then I'd say it is even worse, as you're informing desktop.el 
> about an implementation detail of eglot.el.  If I change that minor 
> mode's name, then I have to change desktop.el as well.  

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.

>  >  > 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"?
> 
> The obarray. 

That's not a source-level feature, so it doesn't help maintenance.

>  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.
> 
> mapatoms is used all the time, it's fast and it can answer that.

We are miscommunicating: I meant finding them without necessarily
running Emacs.  And mapatoms will only help if the corresponding
package was loaded, it won''t help me to find all the packages that
need something from desktop.el.

> I think we use symbol properties very often and to good effect.  For example
> to describe the file-local safety of variables.

Yes, and try finding, for example, all the possible uses of the
'delete-selection' property some day, for the purposes of documenting
what can be done with each value of the property.

> Conversely, putting the eglot-specific line
> in desktop.el is putting eglot.el implementation details outside eglot.el, which
> is bad.

Not in my book, it isn't.  desktop.el is by definition full of details
about different Emacs features, and it is very nice to have them all
in one place.

> So, either way, using the desktop-minor-mode-table for this is a poor choice, 
> which logically means that the information should be stored in the symbol, 
> which exists in the global symbol table (the obarray).

As someone who needs to look in desktop.el for similar details very
frequently, I disagree, sorry.