GNU bug report logs - #56609
[PATCH] Derive `Info-mode' from `special-mode'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56609 in the body.
You can then email your comments to 56609 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Hansen <rhansen <at> rhansen.org>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 01:16:00 -0400

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

Attached patch:

    Derive `Info-mode' from `special-mode'
    
    * lisp/info.el (Info-mode): Derive `Info-mode' from `special-mode'.
    This makes it easier to exclude it from globalized minor modes that
    don't apply to special modes (such as `global-whitespace-mode' and
    `global-display-fill-column-indicator-mode').

[0001-Derive-Info-mode-from-special-mode.patch (text/x-patch, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #8 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Richard Hansen <rhansen <at> rhansen.org>
Cc: 56609 <at> debbugs.gnu.org
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 13:47:48 +0800

Richard Hansen <rhansen <at> rhansen.org> writes:

> Attached patch:
>
>     Derive `Info-mode' from `special-mode'
>          * lisp/info.el (Info-mode): Derive `Info-mode' from
>           `special-mode'.
>     This makes it easier to exclude it from globalized minor modes that
>     don't apply to special modes (such as `global-whitespace-mode' and
>     `global-display-fill-column-indicator-mode').

Did you test this with Info-edit-mode?

(It's in obsolete/, but I still use it daily.)

Message #11 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Richard Hansen <rhansen <at> rhansen.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 56609 <at> debbugs.gnu.org
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 01:52:55 -0400

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

> Did you test this with Info-edit-mode?

No; I will test it tomorrow and report back.

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #14 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Richard Hansen <rhansen <at> rhansen.org>
Cc: 56609 <at> debbugs.gnu.org
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 14:25:03 +0800

Richard Hansen <rhansen <at> rhansen.org> writes:

> No; I will test it tomorrow and report back.

Thanks.

Message #17 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 56609 <at> debbugs.gnu.org, Richard Hansen <rhansen <at> rhansen.org>
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 11:10:45 +0200

Po Lu <luangruo <at> yahoo.com> writes:

>> Attached patch:
>>
>>     Derive `Info-mode' from `special-mode'
>>          * lisp/info.el (Info-mode): Derive `Info-mode' from
>>           `special-mode'.
>>     This makes it easier to exclude it from globalized minor modes that
>>     don't apply to special modes (such as `global-whitespace-mode' and
>>     `global-display-fill-column-indicator-mode').
>
> Did you test this with Info-edit-mode?

Info-edit-mode is derived from text-mode, so I'm not sure what's
supposed to be tested?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #20 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56609 <at> debbugs.gnu.org, Richard Hansen <rhansen <at> rhansen.org>
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 17:25:47 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Info-edit-mode is derived from text-mode, so I'm not sure what's
> supposed to be tested?

That editing the info file still works after running "Info-edit" inside
an Info buffer.

Message #23 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 56609 <at> debbugs.gnu.org, Richard Hansen <rhansen <at> rhansen.org>
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 12:14:14 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> That editing the info file still works after running "Info-edit" inside
> an Info buffer.

I don't think there could be any difference?  We shift from one major
mode to another, whether that one mode is derived or not.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #26 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56609 <at> debbugs.gnu.org, Richard Hansen <rhansen <at> rhansen.org>
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 19:58:30 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I don't think there could be any difference?  We shift from one major
> mode to another, whether that one mode is derived or not.

When changing well established facts about a very old major mode, one
can never be too complacent.

Message #29 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Richard Hansen <rhansen <at> rhansen.org>, "56609 <at> debbugs.gnu.org"
 <56609 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#56609: [PATCH] Derive `Info-mode' from
 `special-mode'
Date: Sun, 17 Jul 2022 14:23:51 +0000

> Derive `Info-mode' from `special-mode'
> 
> * lisp/info.el (Info-mode): Derive `Info-mode' from `special-mode'.
>
> This makes it easier to exclude it from globalized minor modes that
> don't apply to special modes (such as `global-whitespace-mode' and
> global-display-fill-column-indicator-mode').

Is that the only reason?  If so, why is that
a real problem?  And if it is, why is this a
good solution?

If you see some real problem of a particular
globalized minor mode interfering with Info 
mode, why not report that as a specific
problem to be considered for solving?

Emacs has already pondered this question, as
evidenced by the code comment.  It's still a
question, and worth raising.

But to raise it, there should be some (more)
information about what problems there might
be now.  Otherwise, `special-mode', here, is
a solution in search of a problem.

Info mode has been around nearly forever;
`define-derived-mode' has been around at
least since Emacs 20; and `special-mode' has
been here since Emacs 23.

Message #32 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Po Lu <luangruo <at> yahoo.com>, Richard Hansen <rhansen <at> rhansen.org>
Cc: "56609 <at> debbugs.gnu.org" <56609 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#56609: [PATCH] Derive `Info-mode' from
 `special-mode'
Date: Sun, 17 Jul 2022 14:30:54 +0000

> Did you test this with Info-edit-mode?
> 
> (It's in obsolete/, but I still use it daily.)

+1.

(I don't use it daily.  But IMO it should not be
deprecated.  There's nothing wrong with letting
users edit Info nodes directly.

And if you want to prevent them from doing so
accidentally then either ask for confirmation
(once only) or (put 'Info-edit 'disabled "...").

Message #35 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 56609 <at> debbugs.gnu.org, Richard Hansen <rhansen <at> rhansen.org>
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 17:39:12 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> When changing well established facts about a very old major mode, one
> can never be too complacent.

I agree completely.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #38 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Richard Hansen <rhansen <at> rhansen.org>
To: Drew Adams <drew.adams <at> oracle.com>,
 "56609 <at> debbugs.gnu.org" <56609 <at> debbugs.gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: [External] : bug#56609: [PATCH] Derive `Info-mode' from
 `special-mode'
Date: Sun, 17 Jul 2022 18:21:16 -0400

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

Po Lu wrote:
> Did you test this with Info-edit-mode?

Info-edit-mode seems to work fine (after patching a bug in info-edit.el; see bug#56621), though I didn't exercise it much:

  emacs -Q
  C-h i
  M-: (require 'info-edit) RET
  M-x Info-edit RET SPC
  foobarbaz
  C-c C-c y /tmp/testing.info RET

Drew Adams wrote:
>> Derive `Info-mode' from `special-mode'
>>
>> * lisp/info.el (Info-mode): Derive `Info-mode' from `special-mode'.
>>
>> This makes it easier to exclude it from globalized minor modes that 
>> don't apply to special modes (such as `global-whitespace-mode' and 
>> global-display-fill-column-indicator-mode').
> 
> Is that the only reason?

That's my motivating reason.  I guess "improved code readability via consistency" could be considered a secondary reason.

> If so, why is that a real problem?

The alternative doesn't scale. (discussed below)

> And if it is, why is this a good solution?

I'm not enough of an Emacs guru to know if there is a better solution.  After reading [1], [2], and [3] I concluded that `special-mode' was the perfect parent mode for `Info-mode'.  Maybe there are some details that I'm not familiar with, and a better solution exists.  Any suggestions would be appreciated.

[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Major-Mode-Conventions.html
[2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html
[3] https://www.gnu.org/software/emacs/manual/html_node/elisp/Basic-Major-Modes.html

> 
> If you see some real problem of a particular 
> globalized minor mode interfering with Info 
> mode, why not report that as a specific 
> problem to be considered for solving?

In general, globalized minor modes intended for text/code editing convenience are not useful (or even problematic) for major modes whose primary purpose is not editing code or text.  If all major modes were derived from `text-mode', `prog-mode', or `special-mode', such globalized minor modes could either accept only major modes derived from `text-mode'/`prog-mode' or exclude major modes derived from `special-mode'.  Given that not all major modes derive from one of those basic major modes, the conservative approach is to exclude `special-mode'.  This assumes that unknown major modes are probably used for editing text/code, and it's better to have a false positive (a non-editing major mode is mistakenly assumed to be an editing mode) than a false negative (an editing major mode is mistakenly assumed to be a non-editing mode).  This patch fixes one of the false positives.

The globalized minor modes could also explicitly permit/deny specific modes such as `Info-mode', but that approach does not scale well.  It does not make sense to audit all globalized minor modes in Emacs, ELPA, MELPA, etc. and edit each one to explicitly add `Info-mode' to its exclusion list.  Besides being labor intensive, manually curated lists easily become outdated.  One of the values of `special-mode' is the ability to easily filter out all non-editing modes without any code churn.  Let's take advantage of it.

> 
> Emacs has already pondered this question, as 
> evidenced by the code comment.

I looked at the commit history before I posted the patch.  The comment was added in [4] by Stefan Monnier (+CCed).  That commit looks unrelated to the parent mode, so I'm assuming Stefan did what I often do: stumble across something unexpected while working on an unrelated task, and add a comment to help future readers recognize that the code warrants revisiting or at least a justification comment.

[4] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=80a78d23ea06e4bd449096f207fcda41827de9de

> It's still a question, and worth raising.

I figured the easiest way to start the discussion was by posting a patch.  If the change was not controversial, then it could be merged with minimal effort.  Otherwise, the concerns could be raised (as you did).

> 
> But to raise it, there should be some (more) 
> information about what problems there might 
> be now.  Otherwise, `special-mode', here, is 
> a solution in search of a problem.

I don't understand why the bar should be so high for this change.  Why isn't "convenient exclusion from globalized minor modes intended for editing convenience" a good enough reason to make this change?

Is this change riskier than I think it is?  I agree that we don't want to introduce bugs, but being too cautious hinders progress.  Also, there's always `git revert` if something does break.

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #41 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Richard Hansen <rhansen <at> rhansen.org>, Drew Adams <drew.adams <at> oracle.com>, 
 "56609 <at> debbugs.gnu.org" <56609 <at> debbugs.gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 17:10:12 -0700

Richard Hansen <rhansen <at> rhansen.org> writes:

> That's my motivating reason.  I guess "improved code readability via
> consistency" could be considered a secondary reason.

Your patch LGTM.

>> If you see some real problem of a particular
>> globalized minor mode interfering with Info
>> mode, why not report that as a specific
>> problem to be considered for solving?

???

Is there even one reason why Info-mode shouldn't inherit special-mode?

Message #44 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Richard Hansen <rhansen <at> rhansen.org>, "56609 <at> debbugs.gnu.org"
 <56609 <at> debbugs.gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#56609: [PATCH] Derive `Info-mode' from
 `special-mode'
Date: Mon, 18 Jul 2022 00:26:31 +0000

Let me say up front that I really appreciate
your explanation.  Clear & complete.  Reasons
given.  And you did your homework.  A model
that others could benefit from following.

> > globalized minor mode interfering with Info
> > mode, why not report that as a specific
> > problem to be considered for solving?
> 
> In general, globalized minor modes intended for text/code editing
> convenience are not useful (or even problematic) for major modes whose
> primary purpose is not editing code or text.

I don't see globalized (or local) minor modes
as fitting into such a partition of categories.

Some are minor modes intended to provide general
features that are applicable to multiple kinds
of major modes - across your categories - even
across all major modes.  In particular, intended
for both " text/code editing convenience" and
"major modes whose primary purpose is not
editing code or text".

That's a problem (I think) I have with such a
change, a priori.

A similar problem would exist if, say, we had
another category, for modes used for read-only
buffers (no editing at all).  When read-only,
you can't modify, so why not inherit such modes
from some basic `read-only-mode' category?

I don't see a good reason to do so, at least
not in any blanket way.  And I think the same
for your major-mode breakdown for globalized
minor modes.  That Info mode is generally
non-editing doesn't imply that it should
inherit from `special-mode'.

The major-mode conventions don't say that all
major modes should inherit from `text-mode',
`prog-mode', or `special-mode'.  But that
seems to (almost) be an underlying premise
here.  Nor do they say that all major modes
that are generally non-editing should inherit
from `special-mode'.

The paragraph in `Major Mode Conventions' about
`special-mode' calls out the fact that in
general it's not for modes where creating new
buffers should put them in the same mode.  But
that's the case for Info (e.g., with `M-n').

I admit that the same could be said for Dired
etc. modes.  Perhaps that paragraph is no
longer relevant or is poorly worded?  But I
think when it comes to Dired, Rmail, and
Buffer List the relevant creation of buffers
refers to opening files, mail messages, and
listed buffers, respectively.  Info has no
analogous behavior, I think.

> > It's still a question, and worth raising.
> 
> I figured the easiest way to start the discussion was by posting a patch.
> If the change was not controversial, then it could be merged with minimal
> effort.  Otherwise, the concerns could be raised (as you did).
> 
> > But to raise it, there should be some (more)
> > information about what problems there might
> > be now.  Otherwise, `special-mode', here, is
> > a solution in search of a problem.
> 
> I don't understand why the bar should be so high for this change.  Why isn't
> "convenient exclusion from globalized minor modes intended for editing
> convenience" a good enough reason to make this change?

I'm not setting any bar, and I'm not in charge
of any bar setting. ;-)

As for "convenient exclusion from globalized
minor modes intended for editing convenience" -

It's not clear to me that Info mode should be
excluded.  If it were clear that it should be,
then maybe the question of relative convenience
of excluding it would be relevant.

> Is this change riskier than I think it is?  I agree that we don't want to
> introduce bugs, but being too cautious hinders progress.  Also, there's
> always `git revert` if something does break.

I don't say anything about it being risky.
I've only asked why Info mode should inherit
from `special-mode', or more generally (now)
why globalized minor modes need a basic-modes
categorical way to exclude Info mode.

Message #47 received at 56609 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Richard Hansen <rhansen <at> rhansen.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "56609 <at> debbugs.gnu.org" <56609 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: [External] : bug#56609: [PATCH] Derive `Info-mode' from
 `special-mode'
Date: Mon, 18 Jul 2022 08:53:29 +0800

Richard Hansen <rhansen <at> rhansen.org> writes:

> Info-edit-mode seems to work fine (after patching a bug in
> info-edit.el; see bug#56621), though I didn't exercise it much:

I didn't see that bug, probably because ibuffer is already loaded.

>   emacs -Q
>   C-h i
>   M-: (require 'info-edit) RET
>   M-x Info-edit RET SPC
>   foobarbaz
>   C-c C-c y /tmp/testing.info RET

Thanks.

Message #52 received at 56609-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Richard Hansen <rhansen <at> rhansen.org>
Cc: 56609-done <at> debbugs.gnu.org
Subject: Re: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 22:13:43 -0400

Richard Hansen [2022-07-17 01:16:00] wrote:
>     Derive `Info-mode' from `special-mode'
>          * lisp/info.el (Info-mode): Derive `Info-mode' from `special-mode'.
>     This makes it easier to exclude it from globalized minor modes that
>     don't apply to special modes (such as `global-whitespace-mode' and
>     `global-display-fill-column-indicator-mode').

Thanks, pushed to `master`.


        Stefan

Previous Next

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