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

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56407 <at> debbugs.gnu.org
Subject: bug#56407: 29.0.50; desktop.el shouldn't be saving/restoring eglot--managed-mode, which is not for interactive use
Date: Wed, 6 Jul 2022 12:30:28 +0100

[Message part 1 (text/plain, inline)]

On Wed, Jul 6, 2022 at 12:09 PM Eli Zaretskii <eliz <at> 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.

João Távora

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.