bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jens Schmidt
Subject: bug#66780: [PATCH] Improve rectangle-mark-mode when transient-mark-mode is off
Date: Sat, 28 Oct 2023 18:36:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
>> Cc: 66780@debbugs.gnu.org
>> Date: Sat, 28 Oct 2023 14:51:07 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
>> >> Cc: 66780@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]