From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs 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-ID: References: <87y1x7pd53.fsf@gmail.com> <83v8sb73ga.fsf@gnu.org> <87tu7vpc8y.fsf@gmail.com> <83tu7v6kjv.fsf@gnu.org> <83r12y7b0y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b6c66905e321475b" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25701"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56407@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 06 13:31:24 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o93Fb-0006Wk-Uh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Jul 2022 13:31:24 +0200 Original-Received: from localhost ([::1]:57042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o93Fa-0001IC-DT for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Jul 2022 07:31:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46008) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o93EK-0001GZ-If for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 07:30:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58774) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o93EI-0000Hg-PL for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 07:30:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o93EI-0002nI-La for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 07:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2022 11:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56407 X-GNU-PR-Package: emacs Original-Received: via spool by 56407-submit@debbugs.gnu.org id=B56407.165710696910668 (code B ref 56407); Wed, 06 Jul 2022 11:30:02 +0000 Original-Received: (at 56407) by debbugs.gnu.org; 6 Jul 2022 11:29:29 +0000 Original-Received: from localhost ([127.0.0.1]:52671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o93Dk-0002m0-H7 for submit@debbugs.gnu.org; Wed, 06 Jul 2022 07:29:28 -0400 Original-Received: from mail-ot1-f45.google.com ([209.85.210.45]:44686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o93Dh-0002lj-UU for 56407@debbugs.gnu.org; Wed, 06 Jul 2022 07:29:26 -0400 Original-Received: by mail-ot1-f45.google.com with SMTP id m24-20020a0568301e7800b00616b5c114d4so11600205otr.11 for <56407@debbugs.gnu.org>; Wed, 06 Jul 2022 04:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e13im42bzhuUDPoNVYOvO0GO+mMA0EUpR5E/mr6hSdo=; b=pwsgPWu/ZY418je1sJsHn2Uqx995paqkFJVuMDKNEUTwhprvvfHTAQFBtTaDlqOnjt cf4q5OyCPkw1QTw8YsXf6OxCbVoYzAQ35JLgKAReFCMJyBiHUJgFF3kNSjAK/wNce3x/ orYBC5KB24zNQAno7SraZvEzECJMN8LNOt029LCLYlPMMVvNgt8jzbX1AKb6V55qCQI9 4firWcUB7DezrIm36T6yokLk8ANfsMz+YLnAbbj/cVvr1Nc4m0QXTmqYy9+WaQy6qjNG KtJg+DESYwWYpsxQi6NL28podLTpsYdsxzfArV5EsRe1VgAF3NVW+SvSb3JSM+Z5GBuw cgsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e13im42bzhuUDPoNVYOvO0GO+mMA0EUpR5E/mr6hSdo=; b=qiILiKtF2lw9dPokqXUU35Lhi5S6KjwefEIUEzhaNmm3+tCefCySk5jG0u3vGgCawg VOw/TKPPCfIUKJb+G5ULSHz19/URzejPL/jD2eJHpJKOcRzgq6UegD2c0t2HR05BsOKe jbr5FJ0iydP+BK+z38xeBRA9n92JJhA8R3tGMwKa4KEWRouC+kOY6KcffrzDx4Cpv2iy YBDa3TYaKxAw2V1t1JWpy4JABAdD5Hps4h46TpGFXPjnm0Doep92fD3Mf9/DOQe8Jaj4 9AvCX2nDp1rTfL7BbZ9KwYZMVk4utPY/TOtsVJBBnCXEwulWVuT3pjb/azMwmdlGeXAg PZLg== X-Gm-Message-State: AJIora9PYE0MKzGf9bgVxnXk4b5RGlXx1B5rlyHuK0+5mB1ol69cYznl zf+SrUW0cbSAV3Vy5vsnbR+tX5wmRGm9woxh/yk= X-Google-Smtp-Source: AGRyM1vb/WItpSGVB+bg3Ka86aYl8No2zk02VNtrBlbTWv1x2YJkIKRzSa6xdBD7LnwJ6wGn1A3bou+p9yprytyxJ+o= X-Received: by 2002:a9d:4e91:0:b0:616:8273:76e6 with SMTP id v17-20020a9d4e91000000b00616827376e6mr17061067otk.340.1657106960138; Wed, 06 Jul 2022 04:29:20 -0700 (PDT) In-Reply-To: <83r12y7b0y.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:236216 Archived-At: --000000000000b6c66905e321475b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 6, 2022 at 12:09 PM Eli Zaretskii 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 exampl= e 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 loadi= ng > > 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=C3=A3o T=C3=A1vora --000000000000b6c66905e321475b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 6, 2022 at 12:09 PM Eli Zaretskii <eliz@gnu.org> wrote:
=C2=A0
> Oh, it's an autoloaded variable.=C2=A0 OK then, it'll work. It= 'll load in desktop.el
> though.

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

Indeed, I misunderstood. I thought you meant adding t= hat to eglot.el.

But then I'd say it is even w= orse, as you're informing desktop.el
about an implementa= tion detail of eglot.el.=C2=A0 If I change that minor
mode&#= 39;s name, then I have to change desktop.el as well.=C2=A0
<= /div>

>=C2=A0 > I think I like Lars's solution best.
>=C2=A0 I don't: it makes the information spread out and harder to f= ind.
> Depends on whether one thinks using the global symbol table in Elisp i= s
> counts as "spread out". I don't.
What do you mean by "global symbol table"?
<= br>
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.=C2=A0 Because i= n 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.=C2=A0 Except
that even that = question is hard to conceive in this particular case: why would
<= div>someone be concerned about `eglot--managed-mode`, if it's an
implementation detail?

I think we use sym= bol properties very often and to good effect.=C2=A0 For example
t= o describe the file-local safety of variables.
=C2=A0
> There's a nice upside to it, which is it prevents people like me n= ot
> interested in desktop.el at all from having it autoloaded just by load= ing
>=C2=A0 eglot.el.=C2=A0 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.=C2=A0 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.=C2=A0 No other code anywhere else should need to=
consult desktop-minor-mode-table.=C2=A0 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. Converse= ly, putting the eglot-specific line
in desktop.el is putting eglo= t.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 inform= ation should be stored in the symbol,
which exists in the gl= obal symbol table (the obarray).

Interestingly= , a hook variable doesn't have this drawback, btw.=C2=A0 In fact,
<= /div>
they seem to have been designed to avoid this class of problems. = But
d-m-m-table is not a hook variable.

<= div dir=3D"ltr" class=3D"gmail_signature">Jo=C3=A3o T=C3=A1vora
--000000000000b6c66905e321475b--