From: Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 66780@debbugs.gnu.org
Subject: bug#66780: [PATCH] Improve rectangle-mark-mode when transient-mark-mode is off
Date: Sat, 28 Oct 2023 14:51:07 +0200 [thread overview]
Message-ID: <87y1fm3o78.fsf@sappc2.fritz.box> (raw)
In-Reply-To: <83lebnc8tn.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 28 Oct 2023 13:58:28 +0300")
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?
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.
next prev parent reply other threads:[~2023-10-28 12:51 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 [this message]
2023-10-28 13:17 ` Eli Zaretskii
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=87y1fm3o78.fsf@sappc2.fritz.box \
--to=bug-gnu-emacs@gnu.org \
--cc=66780@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=jschmidt4gnu@vodafonemail.de \
/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).