bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Richard Hansen]

[-- Attachment #1.1.1: Type: text/plain, Size: 344 bytes --]

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').

[-- Attachment #1.1.2: 0001-Derive-Info-mode-from-special-mode.patch --]
[-- Type: text/x-patch, Size: 1126 bytes --]

From 81a39987224989774a3f14b70e78cc36722175c5 Mon Sep 17 00:00:00 2001
From: Richard Hansen <rhansen@rhansen.org>
Date: Sun, 17 Jul 2022 00:56:10 -0400
Subject: [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').
---
 lisp/info.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/info.el b/lisp/info.el
index 7fdb893edc..fca4051224 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -4382,7 +4382,7 @@ info-symbols-and-replacements
 
 ;; Autoload cookie needed by desktop.el
 ;;;###autoload
-(define-derived-mode Info-mode nil "Info" ;FIXME: Derive from special-mode?
+(define-derived-mode Info-mode special-mode "Info"
   "Info mode provides commands for browsing through the Info documentation tree.
 Documentation in Info is divided into \"nodes\", each of which discusses
 one topic and contains references to other nodes which discuss related
-- 
2.37.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Richard Hansen <rhansen@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.)

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Richard Hansen]

[-- Attachment #1.1: Type: text/plain, Size: 90 bytes --]

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

No; I will test it tomorrow and report back.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Richard Hansen <rhansen@rhansen.org> writes:

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

Thanks.

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Lars Ingebrigtsen]

Po Lu <luangruo@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

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@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.

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Lars Ingebrigtsen]

Po Lu <luangruo@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

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@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.

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Drew Adams]

> 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.

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Drew Adams]

> 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 "...").

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Lars Ingebrigtsen]

Po Lu <luangruo@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

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Richard Hansen]

[-- Attachment #1.1: Type: text/plain, Size: 4571 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Stefan Kangas]

Richard Hansen <rhansen@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?

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Drew Adams]

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.

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Richard Hansen <rhansen@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.

bug#56609: [PATCH] Derive `Info-mode' from `special-mode'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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