GNU bug report logs - #66780
[PATCH] Improve rectangle-mark-mode when transient-mark-mode is off

Previous Next

To reply to this bug, email your comments to 66780 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Improve rectangle-mark-mode when transient-mark-mode is off
Date: Fri, 27 Oct 2023 22:31:24 +0200

[Message part 1 (text/plain, inline)]

Severity: minor

All issues reported here are about using rectangle-mark-mode (RMM) when
Transient Mark mode (TMM) is off.

Bug#42663 already has mentioned a few issues of this combination, but
IMO did not completely describe or solve them.


So suppose you start in the Emacs source directory tree

  ./src/emacs -Q --eval='(transient-mark-mode -1)' README

When you then press `C-x <SPC>' to enable RMM, the following happens,
which is expected:

1. The mark is NOT activated and, hence, the region-rectangle is NOT
   shown when you move point.  Also, point movement stays regular, in
   that you cannot advance point to after EOL, for example.

Again, this restriction is expected and is described already in commit
06dcd2be5d42 provided by Sean to solve bug#42663.


However, what has not been described yet is that some parts of RMM
actually _are_ active when one enables it with TMM off:

2. The key bindings in `rectangle-mark-mode-map', so that, for example,
   `C-x C-x' does not exchange point and mark, but instead cycles
   through the corners of the rectangle spanned by mark and point (using
   closest accessible buffer positions as an approximation for those
   positions where point regularly cannot be moved to).

   (Short reproducer when starting off the "emacs -Q ..." above:
   M-: (rectangle-mark-mode -1) RET
   M-<   C-x <SPC>   C-4 C-n   C-e   C-x C-x   C-x C-x   C-x C-x)

3. Advices on `region-extract-function' and `region-insert-function', so
   that C-w and C-y still operate on the current rectangle, and not the
   regular region.

   (Short reproducer when starting off the "emacs -Q ..." above:
   M-: (rectangle-mark-mode -1) RET
   M-<   C-x <SPC>   C-4 C-n   C-4 C-f   C-w)


I found 2. and 3. surprising because I would have expected that RMM is
completely off.  Moreover, RMM does not provide a minor mode lighter so
you cannot easily tell whether it is on or off.

I have attempted to improve the situation by providing documentation
(fix A) in a patch on emacs-29, and some minor code fixes (B and C) in a
patch on emacs-master.  That latter patch still has a placeholder
"bug#XXXXX" which needs to be updated once I have a bug number.


* Fix A: Improve Documentation

Here is the text that Sean has already added to emacs/killing.tex in
commit 06dcd2be5d42:

+The region-rectangle works only when the mark is active.  In
+particular, when Transient Mark mode is off (@pxref{Disabled Transient
+Mark}), in addition to typing @kbd{C-x @key{SPC}} you will need to
+activate the mark.

I first tried to extend on that, but then decided to completely redo the
material, like this:

+  rectangle-mark-mode behaves in a slightly different way when
+Transient Mark mode is off (@pxref{Disabled Transient Mark}).  In this
+case, when you enable rectangle-mark-mode, the region-rectangle is not
+automatically enabled.  Accordingly, cursor movement with @kbd{C-f},
+@kbd{C-n} etc.@: is confined to the regularly accessible buffer
+positions.  However, killing and yanking still operate on the
+rectangle spanned by point and mark.  Also @kbd{C-x C-x} still cycles
+through the corners of that rectangle, but only as far as these are at
+buffer positions that are regularly accessible.
+
+  As mentioned above, rectangle-mark-mode persists as long the region
+is active: If the region gets deactivated, rectangle-mark-mode gets
+deactivated as well.  But with disabled Transient mark mode there is
+usually no active region that would get deactivated, and so you have
+to explicitly switch off rectangle-mark-mode when you no longer want
+to use it.
+
+  To experience all benefits of rectangle-mark-mode and the
+region-rectangle when Transient Mark mode is off, you can temporarily
+activate Transient Mark mode after enabling rectangle-mark-mode, for
+example, with @kbd{C-@key{SPC} C-@key{SPC}}.  @xref{Disabled Transient
+Mark}.


I also replaced the somewhat unhelpful reference to parent node
"@xref{Killing}" further up by references to sibling nodes:

 so in a rectangular fashion, and killing and yanking operate on the
-rectangle.  @xref{Killing}.  The mode persists only as long as the
-region is active.
+rectangle.  @xref{Deletion and Killing}, @ref{Yanking}.  The mode
+persists only as long as the region is active.


* Fix B: Use a Minor Mode Lighter

With TMM off and RMM on, the most important indicator of RMM (the
region-rectangle) is not visible.  And since RMM's minor mode lighter is
nil, one has no visible feedback of it still being active.  That can be
surprising since some of its features are still active as described
above.

I tried to improve that by using a minor mode lighter that goes on only
if TMM is off, like this:

+(defvar rectangle-mark-mode-lighter nil
+  "Lighter displayed for `rectangle-mark-mode'.")
+
 ;;;###autoload
 (define-minor-mode rectangle-mark-mode
   "Toggle the region as rectangular.

 Activates the region if it's inactive and Transient Mark mode is
 on.  Only lasts until the region is next deactivated."
-  :lighter nil
+  :lighter rectangle-mark-mode-lighter
   (rectangle--reset-crutches)
   (when rectangle-mark-mode
+    ;; Make us more visible when Transient Mark mode is off and there
+    ;; is no rectangle (bug#XXXXX).
+    (setq rectangle-mark-mode-lighter
+          (and (not transient-mark-mode) " Rect"))


* Fix C: Mark RMM Movement Commands as Shift-Selectable

Finally, to make RMM better usable with shift-select-mode, I added the
necessary interactive specifiers to the RMM-specific movement commands

  rectangle-right-char
  rectangle-left-char
  rectangle-forward-char
  rectangle-backward-char
  rectangle-next-line
  rectangle-previous-line


Please review.

Thanks.

[0001-29-Improve-rectangle-mark-mode-when-transient-mark-mode.patch (text/x-patch, attachment)]

[0001-30-Improve-rectangle-mark-mode-when-transient-mark-mode.patch (text/x-patch, attachment)]

Message #8 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: 66780 <at> debbugs.gnu.org
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sat, 28 Oct 2023 09:24:19 +0300

> Date: Fri, 27 Oct 2023 22:31:24 +0200
> From:  Jens Schmidt via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> I have attempted to improve the situation by providing documentation
> (fix A) in a patch on emacs-29, and some minor code fixes (B and C) in a
> patch on emacs-master.  That latter patch still has a placeholder
> "bug#XXXXX" which needs to be updated once I have a bug number.

Do we expect people to use rectangle-mark-mode with
transient-mark-mode turned off?  The description of the behavior in
that case is complicated and confusing, and I wonder whether we should
have it in the manual.  We could just say that the behavior is
slightly different, and that we don't recommend turning off
transient-mark-mode if the user wants to use rectangle-mark-mode.

> * Fix B: Use a Minor Mode Lighter
> 
> With TMM off and RMM on, the most important indicator of RMM (the
> region-rectangle) is not visible.  And since RMM's minor mode lighter is
> nil, one has no visible feedback of it still being active.  That can be
> surprising since some of its features are still active as described
> above.

Again, not sure indicating this combination is worth our while,
especially since the real estate on the mode line is already too
scarce, so much so that in many windows important information at the
end of the mode line is pushed beyond the limits.

Why do you think it's important to have this combination prominently
documented and indicated at run time?  Do we have any evidence that it
is used frequently enough to justify these measures?

Message #11 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66780 <at> debbugs.gnu.org
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sat, 28 Oct 2023 12:50:48 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Fri, 27 Oct 2023 22:31:24 +0200
>> From:  Jens Schmidt via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> I have attempted to improve the situation by providing documentation
>> (fix A) in a patch on emacs-29, and some minor code fixes (B and C) in a
>> patch on emacs-master.  That latter patch still has a placeholder
>> "bug#XXXXX" which needs to be updated once I have a bug number.
>
> Do we expect people to use rectangle-mark-mode with
> transient-mark-mode turned off?

Sean and me make two already.  More seriously, I use shift-select-mode
with transient-mark-mode turned off, because I'd like to have the region
inactive as much as possible.

And I always have been looking for an option to more easily operate on
rectangles at EOL, like in the following example:

              vvv add another column with "foo" here
  foo
  foo bar
  foo bar baz

rectangle-mark-mode seems to fill that gap nicely, in particular, since
it could be used with shift-select-mode once the interactive specifiers
have been amended accordingly.  In the above example, I move to the last
line, then: C-e, C-x <SPC>, C-3 S-<up>, C-x r t, all the while staying
in my usual shift-select work flow.

> The description of the behavior in that case is complicated and
> confusing, and I wonder whether we should have it in the manual.  We
> could just say that the behavior is slightly different, and that we
> don't recommend turning off transient-mark-mode if the user wants to
> use rectangle-mark-mode.

Agreed in general but see above for a use-case where the combination
seems helpful.

Another option would have been to turn off the confusing bits of RMM
when *permanent* TMM is off.  I would have preferred that, actually: A
rectangle-mark-mode that *really* only shows the region-rectangle when
permanent TMM is off but leaves all other functionality (kill, yank, C-x
C-x) unchanged.  In that case a conditional minor mode lighter would not
be neccessary, either.

What do you think about that option?

>> * Fix B: Use a Minor Mode Lighter
>>
>> With TMM off and RMM on, the most important indicator of RMM (the
>> region-rectangle) is not visible.  And since RMM's minor mode lighter is
>> nil, one has no visible feedback of it still being active.  That can be
>> surprising since some of its features are still active as described
>> above.
>
> Again, not sure indicating this combination is worth our while,
> especially since the real estate on the mode line is already too
> scarce, so much so that in many windows important information at the
> end of the mode line is pushed beyond the limits.

Agreed on the real estate, but the information would be displayed only
in very specific circumstances, for very few (?) users, and only for a
very short time, since that minor mode has a short lifetime.  But WHEN
it is displayed, it could save confusion and inadvertent edits.

> Why do you think it's important to have this combination prominently
> documented and indicated at run time?  Do we have any evidence that it
> is used frequently enough to justify these measures?

No poll results available.  But I guess that users coming from other
editors could prefer

  transient-mark-mode: off
  shift-select-mode:   on

since this is closer to their previous experience, where the region
always deactivates itself as soon as you move the (unshifted) cursor.

Finally, do you also have any objections on fix C, adding the "^"
markers to the interactive specs of the movement commands?  Or would
that bit be OK?

Message #14 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: 66780 <at> debbugs.gnu.org
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sat, 28 Oct 2023 13:58:28 +0300

> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Cc: 66780 <at> debbugs.gnu.org
> Date: Sat, 28 Oct 2023 12:50:48 +0200
> 
> Another option would have been to turn off the confusing bits of RMM
> when *permanent* TMM is off.  I would have preferred that, actually: A
> rectangle-mark-mode that *really* only shows the region-rectangle when
> permanent TMM is off but leaves all other functionality (kill, yank, C-x
> C-x) unchanged.  In that case a conditional minor mode lighter would not
> be neccessary, either.
> 
> What do you think about that option?

It would be a backward-incompatible change, so it has even more
disadvantages IMO.

> > Why do you think it's important to have this combination prominently
> > documented and indicated at run time?  Do we have any evidence that it
> > is used frequently enough to justify these measures?
> 
> No poll results available.  But I guess that users coming from other
> editors could prefer
> 
>   transient-mark-mode: off
>   shift-select-mode:   on
> 
> since this is closer to their previous experience, where the region
> always deactivates itself as soon as you move the (unshifted) cursor.

I actually think most users want transient-mark-mode turned ON, since
that is closer what other editors do.

> Finally, do you also have any objections on fix C, adding the "^"
> markers to the interactive specs of the movement commands?  Or would
> that bit be OK?

You never explained why that would be advantageous, nor even what
effect will that have.

Message #17 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66780 <at> debbugs.gnu.org
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sat, 28 Oct 2023 14:51:07 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
>> Cc: 66780 <at> debbugs.gnu.org
>> Date: Sat, 28 Oct 2023 12:50:48 +0200

A general question first: Notwithstanding the discussion of how many use
it, do we agree that the combination of using shift-select-mode
_without_ permanent transient-mark-mode ("shift-select-mode-only
scenario") is a supported scenario in Emacs?

Because that's what this bug is about, in the end: Instead of
discouraging the shift-select-mode-only users to use rectangle-mark-mode
I would like to find a solution that helps them.  Without affecting any
other users.  Is that not a valid, probably even noble ambition?

>> Another option would have been to turn off the confusing bits of RMM
>> when *permanent* TMM is off.  I would have preferred that, actually: A
>> rectangle-mark-mode that *really* only shows the region-rectangle when
>> permanent TMM is off but leaves all other functionality (kill, yank, C-x
>> C-x) unchanged.  In that case a conditional minor mode lighter would not
>> be neccessary, either.
>>
>> What do you think about that option?
>
> It would be a backward-incompatible change, so it has even more
> disadvantages IMO.

It would be backward-incompatible only where the behavior currently is
confusing.  For those who use permanent transient-mark-mode nothing
would change.

Another option, not featuring backward-incompatiblity at all but still
helping shift-select-mode-only users: Adding a rectangle-light-mark-mode
that provides the selection capabilities, but not the editing surprises
of rectangle-mark-mode.  The documentation could then provide the
recommendation to use that new mode instead of the other.

>> No poll results available.  But I guess that users coming from other
>> editors could prefer
>>
>>   transient-mark-mode: off
>>   shift-select-mode:   on
>>
>> since this is closer to their previous experience, where the region
>> always deactivates itself as soon as you move the (unshifted) cursor.
>
> I actually think most users want transient-mark-mode turned ON, since
> that is closer what other editors do.

I disagree here.  Other editors do the equivalent of shift-select-mode.
I haven't seen yet an editor that (exaggerating) randomly activates the
region and then leaves it on until you press C-g.

>> Finally, do you also have any objections on fix C, adding the "^"
>> markers to the interactive specs of the movement commands?  Or would
>> that bit be OK?
>
> You never explained why that would be advantageous, nor even what
> effect will that have.

Sorry.  It would have the effect documented for `interactive':

  If the string begins with ‘^’ and ‘shift-select-mode’ is non-nil,
   Emacs first calls the function ‘handle-shift-selection’.

Function `handle-shift-selection' in that case temporarily enables
transient-mark-mode and pushes the mark, which in turn activates the
region-rectangle provided that RMM is enabled.  The effect would be that
I can use the shifted cursor keys to select a region-rectangle even if
transient-mark-mode is not permanently on.  Which I consider
advantageous.

Message #20 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: 66780 <at> debbugs.gnu.org
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sat, 28 Oct 2023 16:17:39 +0300

> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Cc: 66780 <at> debbugs.gnu.org
> Date: Sat, 28 Oct 2023 14:51:07 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> >> Cc: 66780 <at> debbugs.gnu.org
> >> Date: Sat, 28 Oct 2023 12:50:48 +0200
> 
> A general question first: Notwithstanding the discussion of how many use
> it, do we agree that the combination of using shift-select-mode
> _without_ permanent transient-mark-mode ("shift-select-mode-only
> scenario") is a supported scenario in Emacs?

It is supported de-facto, yes.  But that doesn't mean we must
recommend that people use it, if the results are confusing and hard to
predict and understand.  Whoever uses this combination, if they
understand the consequences, are free to use it, of course.  But if
they don't understand the consequences well enough to be using this
combination in a way that's useful to them, then there's nothing wrong
with saying don't do that.

> Because that's what this bug is about, in the end: Instead of
> discouraging the shift-select-mode-only users to use rectangle-mark-mode
> I would like to find a solution that helps them.  Without affecting any
> other users.  Is that not a valid, probably even noble ambition?

Not necessarily, not where I stand.  You found something that you'd
like to fix for your own reasons.  That is perfectly legitimate, and
you have all the means of doing so locally: that's what makes Emacs
the perfectly customizable tool.  But when you come here and propose
patches, you say something else: that your personal preferences and
itches you'd like to scratch are important enough and general enough
to make those changes in Emacs core so that they affect everyone else.
And that is something that doesn't automatically follows from your
personal preferences and use patterns.  It needs more serious
justifications.

IOW, when you call this a "bug", I can easily agree with you if "bug"
is interpreted as "bug under your personal preferences and use
patterns".  But if you want to convince me that it is a "bug" worthy
of making changes in Emacs that will affect everyone, it is not enough
to describe your own personal use case.

> >> Another option would have been to turn off the confusing bits of RMM
> >> when *permanent* TMM is off.  I would have preferred that, actually: A
> >> rectangle-mark-mode that *really* only shows the region-rectangle when
> >> permanent TMM is off but leaves all other functionality (kill, yank, C-x
> >> C-x) unchanged.  In that case a conditional minor mode lighter would not
> >> be neccessary, either.
> >>
> >> What do you think about that option?
> >
> > It would be a backward-incompatible change, so it has even more
> > disadvantages IMO.
> 
> It would be backward-incompatible only where the behavior currently is
> confusing.

It is confusing for you, I get that.  But we have no reason to believe
it's confusing for everyone else.

> Another option, not featuring backward-incompatiblity at all but still
> helping shift-select-mode-only users: Adding a rectangle-light-mark-mode
> that provides the selection capabilities, but not the editing surprises
> of rectangle-mark-mode.  The documentation could then provide the
> recommendation to use that new mode instead of the other.

And here you suggest a complication in Emacs, which again, as far as
I'm concerned, requires to be justified.  Once again I ask: why not
make these changes, or others that you propose, in your own local
Emacs, and be done?  Emacs makes it very easy to make such changes,
definitely for someone who can write patches you submitted in this bug
report.  Why do you insist on making these changes in upstream, to
affect everyone else, when all you have is your personal negative
experience with these features?

> > I actually think most users want transient-mark-mode turned ON, since
> > that is closer what other editors do.
> 
> I disagree here.  Other editors do the equivalent of shift-select-mode.

They have both, because region is highlighted not only by
shift-movements, but also by other means.  We turned on
transient-mark-mode by default because we have ample evidence that
many people prefer it.  I don't think this has changed since we made
that decision.

> I haven't seen yet an editor that (exaggerating) randomly activates the
> region and then leaves it on until you press C-g.

It is true that the Emacs behavior under transient-mark-mode is not
exactly like that of other applications, but it is very close where
the related behaviors overlap (C-g is not a good example because it is
quite unique to Emacs).

> >> Finally, do you also have any objections on fix C, adding the "^"
> >> markers to the interactive specs of the movement commands?  Or would
> >> that bit be OK?
> >
> > You never explained why that would be advantageous, nor even what
> > effect will that have.
> 
> Sorry.  It would have the effect documented for `interactive':
> 
>   If the string begins with ‘^’ and ‘shift-select-mode’ is non-nil,
>    Emacs first calls the function ‘handle-shift-selection’.
> 
> Function `handle-shift-selection' in that case temporarily enables
> transient-mark-mode and pushes the mark, which in turn activates the
> region-rectangle provided that RMM is enabled.  The effect would be that
> I can use the shifted cursor keys to select a region-rectangle even if
> transient-mark-mode is not permanently on.  Which I consider
> advantageous.

Maybe we should do this.  I'd like to hear opinions of others about
this, in particular that of Stefan Kangas (CC'ed).

Message #23 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66780 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sat, 28 Oct 2023 18:36:49 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
>> Cc: 66780 <at> debbugs.gnu.org
>> Date: Sat, 28 Oct 2023 14:51:07 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
>> >> Cc: 66780 <at> debbugs.gnu.org
>> >> Date: Sat, 28 Oct 2023 12:50:48 +0200
>>
>> A general question first: Notwithstanding the discussion of how many use
>> it, do we agree that the combination of using shift-select-mode
>> _without_ permanent transient-mark-mode ("shift-select-mode-only
>> scenario") is a supported scenario in Emacs?
>
> It is supported de-facto, yes.  But that doesn't mean we must
> recommend that people use it, if the results are confusing and hard to
> predict and understand.  Whoever uses this combination, if they
> understand the consequences, are free to use it, of course.  But if
> they don't understand the consequences well enough to be using this
> combination in a way that's useful to them, then there's nothing wrong
> with saying don't do that.
>
>> Because that's what this bug is about, in the end: Instead of
>> discouraging the shift-select-mode-only users to use rectangle-mark-mode
>> I would like to find a solution that helps them.  Without affecting any
>> other users.  Is that not a valid, probably even noble ambition?
>
> Not necessarily, not where I stand.  You found something that you'd
> like to fix for your own reasons.  That is perfectly legitimate, and
> you have all the means of doing so locally: that's what makes Emacs
> the perfectly customizable tool.  But when you come here and propose
> patches, you say something else: that your personal preferences and
> itches you'd like to scratch are important enough and general enough
> to make those changes in Emacs core so that they affect everyone else.
> And that is something that doesn't automatically follows from your
> personal preferences and use patterns.  It needs more serious
> justifications.
>
> IOW, when you call this a "bug", I can easily agree with you if "bug"
> is interpreted as "bug under your personal preferences and use
> patterns".  But if you want to convince me that it is a "bug" worthy
> of making changes in Emacs that will affect everyone, it is not enough
> to describe your own personal use case.
>
>> >> Another option would have been to turn off the confusing bits of RMM
>> >> when *permanent* TMM is off.  I would have preferred that, actually: A
>> >> rectangle-mark-mode that *really* only shows the region-rectangle when
>> >> permanent TMM is off but leaves all other functionality (kill, yank, C-x
>> >> C-x) unchanged.  In that case a conditional minor mode lighter would not
>> >> be neccessary, either.
>> >>
>> >> What do you think about that option?
>> >
>> > It would be a backward-incompatible change, so it has even more
>> > disadvantages IMO.
>>
>> It would be backward-incompatible only where the behavior currently is
>> confusing.
>
> It is confusing for you, I get that.  But we have no reason to believe
> it's confusing for everyone else.
>
>> Another option, not featuring backward-incompatiblity at all but still
>> helping shift-select-mode-only users: Adding a rectangle-light-mark-mode
>> that provides the selection capabilities, but not the editing surprises
>> of rectangle-mark-mode.  The documentation could then provide the
>> recommendation to use that new mode instead of the other.
>
> And here you suggest a complication in Emacs, which again, as far as
> I'm concerned, requires to be justified.  Once again I ask: why not
> make these changes, or others that you propose, in your own local
> Emacs, and be done?  Emacs makes it very easy to make such changes,
> definitely for someone who can write patches you submitted in this bug
> report.  Why do you insist on making these changes in upstream, to
> affect everyone else, when all you have is your personal negative
> experience with these features?

Thanks for your detailed reply, which I feel somewhat hard to reply in
the usual inlined style, so please let me allow to pick your points and
reply to them:

> And that is something that doesn't automatically follows from your
> personal preferences and use patterns.  It needs more serious
> justifications.

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.

> 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.

> You found something that you'd
> like to fix for your own reasons.

Really?  Go through all that effort of carefully describing the issue
and discussing with you just for my own reasons, where I have (indeed)
fixed that issue in my .emacs in 10mins?

> Once again I ask: why not
> make these changes, or others that you propose, in your own local
> Emacs, and be done?
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^

That's a rather discouraging request.  Is is somewhat in contrast to
this statements from the README:

  You may encounter bugs in this release.  If you do, please report
  them; your bug reports are valuable contributions to the FSF, since
  they allow us to notice and fix problems on machines we don't have, or
  in code we don't use often.

So are you asking me not to file any bugs?  Any "edge-case bugs" in code
that you don't use often?  Or, in other words: Which of my change
requests so far had truly the quality to affect me and only me?

Message #26 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: 66780 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sat, 28 Oct 2023 19:47:34 +0300

> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>,  66780 <at> debbugs.gnu.org
> Date: Sat, 28 Oct 2023 18:36:49 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > And that is something that doesn't automatically follows from your
> > personal preferences and use patterns.  It needs more serious
> > justifications.
> 
> 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.

> > 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.

> > You found something that you'd
> > like to fix for your own reasons.
> 
> Really?  Go through all that effort of carefully describing the issue
> and discussing with you just for my own reasons, where I have (indeed)
> fixed that issue in my .emacs in 10mins?
> 
> > Once again I ask: why not
> > make these changes, or others that you propose, in your own local
> > Emacs, and be done?
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> That's a rather discouraging request.  Is is somewhat in contrast to
> this statements from the README:
> 
>   You may encounter bugs in this release.  If you do, please report
>   them; your bug reports are valuable contributions to the FSF, since
>   they allow us to notice and fix problems on machines we don't have, or
>   in code we don't use often.
> 
> So are you asking me not to file any bugs?

Of course not.  But please don't expect us to agree with and accept
every change you suggest.  Each one of them is judged on its own
right, and not all of them will find their way into Emacs.  Sometimes,
we will not even agree that what you consider a bug is indeed a bug.

> 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?  Then I
think I already answered that: the first 2 I tend not to accept, the
last one I think could be accepted, and I'd like to hear opinions of
others about it.

Message #29 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66780 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sat, 28 Oct 2023 20:30:00 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
>> Cc: Stefan Kangas <stefankangas <at> gmail.com>,  66780 <at> debbugs.gnu.org
>> Date: Sat, 28 Oct 2023 18:36:49 +0200
>> 
>> Eli Zaretskii <eliz <at> 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?

>> > 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?

>> > Once again I ask: why not
>> > make these changes, or others that you propose, in your own local
>> > Emacs, and be done?
>>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> That's a rather discouraging request.  [...]
>>
>> 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.

Message #32 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: 66780 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sat, 28 Oct 2023 21:48:57 +0300

> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Cc: 66780 <at> debbugs.gnu.org,  stefankangas <at> gmail.com
> Date: Sat, 28 Oct 2023 20:30:00 +0200
> 
> Eli Zaretskii <eliz <at> 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.

Message #35 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66780 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Sun, 29 Oct 2023 15:49:03 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> 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.

More or less agreeing.

> 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.

Still disagreeing, but anyway.

Let's wait for Stefan's verdict on fix C.

Thanks.

Message #38 received at 66780 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: 66780 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#66780: [PATCH] Improve rectangle-mark-mode when
 transient-mark-mode is off
Date: Thu, 02 Nov 2023 08:33:57 +0200

> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Cc: 66780 <at> debbugs.gnu.org,  stefankangas <at> gmail.com
> Date: Sun, 29 Oct 2023 15:49:03 +0100
> 
> Let's wait for Stefan's verdict on fix C.

Stefan, would you please voice your opinion on that?

Thanks.

Previous Next

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