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.