unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Zachary Kanfer <zkanfer@gmail.com>
Cc: rms@gnu.org, juri@linkov.net, ruijie@netyu.xyz,
	62892@debbugs.gnu.org, drew.adams@oracle.com,
	monnier@iro.umontreal.ca
Subject: bug#62892: proposal to extend mark-sexp to go forward and backward on command
Date: Wed, 31 May 2023 15:01:39 +0300	[thread overview]
Message-ID: <83mt1kg15o.fsf@gnu.org> (raw)
In-Reply-To: <CAFXT+RPQPxx4mQBFYhqdScUaynQ5oWxL+pzZkG4k2Ba=26=WRA@mail.gmail.com> (message from Zachary Kanfer on Tue, 30 May 2023 23:23:13 -0400)

> From: Zachary Kanfer <zkanfer@gmail.com>
> Date: Tue, 30 May 2023 23:23:13 -0400
> Cc: rms@gnu.org, ruijie@netyu.xyz, 62892@debbugs.gnu.org, 
> 	monnier@iro.umontreal.ca, drew.adams@oracle.com, juri@linkov.net
> 
> This is interesting. Let me see if I'm understanding properly. In this, I'll talk only about sexps, but I
> believe this argument should apply to all the forms we've talked about (word, sexp, paragraph, defun,
> page). These commands should:
> 
> 1. Always move forward/back by ARG sexps (defaulting to 1), setting the region on all sexps it moves
> across.
> 
> I'm in agreement with #1, for sure. That is the basis for what I wanted initially.
> 
> 2. Ignore whether transient-mark-mode is enabled.
> 3. Don't change behavior if the region is active or not.
> 
> #2 and #3 I believe can be considered together. There are a few things that could do this, but I think
> what you're saying is that this function should *only* move mark.That is, point should stay the same no
> matter what is called here. Additionally, it should activate mark. Is that what you meant?

No, it should only move point, not the mark.  The mark should stay
where point was before invoking the command.

Whether it should activate the mark is open to discussion.  One
possibility is that the command will work like shift-select commands.
Another possibility is that it should activate the mark only if
transient-mark-mode is turned ON, like other commands that push the
mark.

> My understanding was that #'use-region-p (which checks transient-mark-mode, and whether the region
> is active) is a standard way for determining whether to act on the region or not, and should generally
> be looked at before acting on the region. Is that not accurate?

This is correct, but only for commands that do something with the text
in the region: limit search/replace to it, or spell-check the text in
it, etc.  mark-sexp doesn't do anything like that, it actually
_modifies_ the region.  So the fact that it changes its effect
depending on whether the region is active is IMO pretty confusing and
unexpected.





  reply	other threads:[~2023-05-31 12:01 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17  2:25 bug#62892: proposal to extend mark-sexp to go forward and backward on command Zachary Kanfer
2023-04-17  3:06 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-20  5:25   ` Zachary Kanfer
2023-04-20  7:16     ` Eli Zaretskii
2023-04-21  5:04       ` Zachary Kanfer
2023-04-21  6:07         ` Eli Zaretskii
2023-04-21  7:24           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-21  9:51           ` Visuwesh
2023-04-21 13:10   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-23  5:33     ` Zachary Kanfer
2023-04-25 22:26       ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-26  4:41         ` Zachary Kanfer
2023-04-26  6:28           ` Eli Zaretskii
2023-04-27  2:37             ` Zachary Kanfer
2023-04-27 12:25               ` Eli Zaretskii
2023-04-27 18:12                 ` Juri Linkov
2023-04-28  5:28                   ` Zachary Kanfer
2023-05-06  8:49                   ` Eli Zaretskii
2023-04-28 17:04       ` Juri Linkov
2023-04-28 19:28         ` Drew Adams
2023-05-04  4:48           ` Zachary Kanfer
2023-05-08 12:28             ` Zachary Kanfer
2023-05-18  3:17               ` Zachary Kanfer
2023-05-18  6:52                 ` Eli Zaretskii
2023-05-21  5:46                   ` Zachary Kanfer
2023-05-21  5:58                     ` Eli Zaretskii
2023-05-21 14:31                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-21 14:39                         ` Eli Zaretskii
2023-05-21 14:54                           ` Eli Zaretskii
2023-05-21 14:56                         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-21 15:11                           ` Eli Zaretskii
2023-05-21 15:41                             ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-22 22:02                 ` Richard Stallman
2023-05-23 14:11                   ` Zachary Kanfer
2023-05-25 22:32                     ` Richard Stallman
2023-05-26  6:06                       ` Eli Zaretskii
2023-05-31  3:23                         ` Zachary Kanfer
2023-05-31 12:01                           ` Eli Zaretskii [this message]
2023-06-01  3:54                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-01  6:32                               ` Eli Zaretskii
2023-05-03  6:10         ` Zachary Kanfer
2023-05-03 17:29           ` Juri Linkov
2023-04-17  7:11 ` Juri Linkov

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=83mt1kg15o.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=62892@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=juri@linkov.net \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    --cc=ruijie@netyu.xyz \
    --cc=zkanfer@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).