On Wed, Jul 6, 2022 at 12:09 PM Eli Zaretskii <
eliz@gnu.org> wrote:
> 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?
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.
> > 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.
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.
But typically I think, the question would be: "Why isn't this mode X being
handled as I expect it to?", and then the answer would be easy. Except
that even that question is hard to conceive in this particular case: why would
someone be concerned about `eglot--managed-mode`, if it's an
implementation detail?
I think we use symbol properties very often and to good effect. For example
to describe the file-local safety of variables.
> 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?
See above. I thought you meant putting the line into eglot.el which would
work but needs loading desktop.el. Conversely, putting the eglot-specific line
in desktop.el is putting eglot.el implementation details outside eglot.el, which
is bad.
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).
Interestingly, a hook variable doesn't have this drawback, btw. In fact,
they seem to have been designed to avoid this class of problems. But
d-m-m-table is not a hook variable.