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

Previous Next

Full log

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)]

Previous Next

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