From: "João Távora" <joaotavora@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 56407@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 [thread overview]
Message-ID: <CALDnm50JmcUCZ7zd+Pei=xJAhbezpgG2Gp7FW-XYTTwfqqkWNg@mail.gmail.com> (raw)
In-Reply-To: <83r12y7b0y.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3221 bytes --]
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.
João Távora
[-- Attachment #2: Type: text/html, Size: 4603 bytes --]
next prev parent reply other threads:[~2022-07-06 11:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-05 19:34 bug#56407: 29.0.50; desktop.el shouldn't be saving/restoring eglot--managed-mode, which is not for interactive use João Távora
2022-07-05 19:40 ` Eli Zaretskii
2022-07-05 19:53 ` João Távora
2022-07-06 2:29 ` Eli Zaretskii
2022-07-06 8:12 ` João Távora
2022-07-06 11:09 ` Eli Zaretskii
2022-07-06 11:30 ` João Távora [this message]
2022-07-06 11:37 ` Lars Ingebrigtsen
2022-07-06 12:48 ` Eli Zaretskii
2022-07-06 12:59 ` João Távora
2022-07-06 13:12 ` Eli Zaretskii
2022-07-06 13:19 ` João Távora
2022-07-06 13:23 ` João Távora
2022-07-06 13:39 ` Stefan Kangas
2022-07-06 13:47 ` João Távora
2022-07-06 13:52 ` Stefan Kangas
2022-07-06 13:52 ` Lars Ingebrigtsen
2022-07-06 13:59 ` João Távora
2022-07-05 22:52 ` João Távora
2022-07-06 2:34 ` Eli Zaretskii
2022-07-06 8:27 ` João Távora
2022-07-05 19:41 ` Lars Ingebrigtsen
2022-07-05 19:56 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALDnm50JmcUCZ7zd+Pei=xJAhbezpgG2Gp7FW-XYTTwfqqkWNg@mail.gmail.com' \
--to=joaotavora@gmail.com \
--cc=56407@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.