From: Richard Hansen <rhansen@rhansen.org>
To: Drew Adams <drew.adams@oracle.com>,
"56609@debbugs.gnu.org" <56609@debbugs.gnu.org>,
Po Lu <luangruo@yahoo.com>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#56609: [PATCH] Derive `Info-mode' from `special-mode'
Date: Sun, 17 Jul 2022 18:21:16 -0400 [thread overview]
Message-ID: <5f242723-f776-2ff7-2491-5ed4e7c32172@rhansen.org> (raw)
In-Reply-To: <SJ0PR10MB54888D6B86BCC2E28D76AEDAF38D9@SJ0PR10MB5488.namprd10.prod.outlook.com>
[-- 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 --]
next prev parent reply other threads:[~2022-07-17 22:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-17 5:16 bug#56609: [PATCH] Derive `Info-mode' from `special-mode' Richard Hansen
2022-07-17 5:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-17 5:52 ` Richard Hansen
2022-07-17 6:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-17 9:10 ` Lars Ingebrigtsen
2022-07-17 9:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-17 10:14 ` Lars Ingebrigtsen
2022-07-17 11:58 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-17 15:39 ` Lars Ingebrigtsen
2022-07-17 14:30 ` Drew Adams
2022-07-17 14:23 ` Drew Adams
2022-07-17 22:21 ` Richard Hansen [this message]
2022-07-18 0:10 ` Stefan Kangas
2022-07-18 0:26 ` Drew Adams
2022-07-18 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-18 2:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5f242723-f776-2ff7-2491-5ed4e7c32172@rhansen.org \
--to=rhansen@rhansen.org \
--cc=56609@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=larsi@gnus.org \
--cc=luangruo@yahoo.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.