unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jens Schmidt <jschmidt4gnu@vodafonemail.de>,
	Stefan Kangas <stefankangas@gmail.com>
Cc: 66780@debbugs.gnu.org
Subject: bug#66780: [PATCH] Improve rectangle-mark-mode when transient-mark-mode is off
Date: Sat, 28 Oct 2023 16:17:39 +0300	[thread overview]
Message-ID: <83edhedgy4.fsf@gnu.org> (raw)
In-Reply-To: <87y1fm3o78.fsf@sappc2.fritz.box> (message from Jens Schmidt on Sat, 28 Oct 2023 14:51:07 +0200)

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

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





  reply	other threads:[~2023-10-28 13:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-27 20:31 bug#66780: [PATCH] Improve rectangle-mark-mode when transient-mark-mode is off Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-28  6:24 ` Eli Zaretskii
2023-10-28 10:50   ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-28 10:58     ` Eli Zaretskii
2023-10-28 12:51       ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-28 13:17         ` Eli Zaretskii [this message]
2023-10-28 16:36           ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-28 16:47             ` Eli Zaretskii
2023-10-28 18:30               ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-28 18:48                 ` Eli Zaretskii
2023-10-29 14:49                   ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-02  6:33                     ` Eli Zaretskii

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83edhedgy4.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=66780@debbugs.gnu.org \
    --cc=jschmidt4gnu@vodafonemail.de \
    --cc=stefankangas@gmail.com \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).