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

[Richard Hansen]

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
Description: OpenPGP digital signature