bug#66780: [PATCH] Improve rectangle-mark-mode when transient-mark-mode is off

[Eli Zaretskii]

> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Cc: 66780@debbugs.gnu.org,  stefankangas@gmail.com
> Date: Sat, 28 Oct 2023 20:30:00 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It's not only my "personal preferences and use patterns".  See Sean's
> >> bug#42663 plus Michael's bug#16066.  So every now and then somebody
> >> having transient-mark-mode switched off comes across this.
> >
> > Yes, I know.  But that doesn't remove the need to justify a change to
> > Emacs.
> 
> And what justifies a change?  Let's focus on the lighter change: What
> would justify this?  More frequent user demand?

Serious reasons to make the change.  For this particular one, I guess
arguments for why this situation is not as obscure and unimportant as
it looks.  Obscure aspects of Emacs use do not get to be described in
the user manual, since the manual is not supposed to describe every
command, variable, and function we have in Emacs, only those deemed
important enough.  For the rest, there are the doc string and Help
commands that search those doc strings and help users find those
symbols even though they are not in the manual.

> >> > Why do you insist on making these changes in upstream, to
> >> > affect everyone else [...]
> >> 
> >> It's not "everyone else".  My solution of adding a conditional minor
> >> mode lighter has been designed to specifically affect (== help) only
> >> those that do not use permanent transient-mark-mode.
> >
> > It's one more minor mode with one more lighter.  So yes, it affects
> > everyone else.
> 
> By its mere presence in `minor-mode-alist', mapping to a variable there
> that is nil most of the time?  How would that affect you, for example?

For starters, I'd need to know about it, so I could understand what it
tells me when it is present.  When it _is_ present, it's quite
possible that some other mode-line information important to me will be
pushed outside of the visible part.

> >> Or, in other words: Which of my change requests so far had truly the
> >> quality to affect me and only me?
> >
> > Are you asking about the 3 suggestions in this bug report?
> 
> The double plural you have been using in "these change*s*, or other*s*
> that you propose" seemed to refer to changes other than those dicussed
> in this report.  I take it you did not mean that and will continue to
> file bugs.  After all, most of my past reports had some effect on Emacs,
> and almost always the one I intended.

When a bug reports that Emacs doesn't do something it ought to do,
like when it leaves a file with incorrect mode bits, the need to fix
it is clear and doesn't need to be justified.  That is not the case
here, though.