unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Zachary Kanfer <zkanfer@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
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: Tue, 30 May 2023 23:23:13 -0400	[thread overview]
Message-ID: <CAFXT+RPQPxx4mQBFYhqdScUaynQ5oWxL+pzZkG4k2Ba=26=WRA@mail.gmail.com> (raw)
In-Reply-To: <83ttvzlj88.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3085 bytes --]

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?

> But adding new commands that still change behavior in mysterious ways
> depending on transient-mark-mode and active region is not something I
> would like to do.

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?


On Fri, May 26, 2023 at 2:06 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: ruijie@netyu.xyz, 62892@debbugs.gnu.org, monnier@iro.umontreal.ca,
> >  drew.adams@oracle.com, juri@linkov.net
> > From: Richard Stallman <rms@gnu.org>
> > Date: Thu, 25 May 2023 18:32:56 -0400
> >
> > I don't think we could find standard key bindings that are easy enough
> > to be worth thinking about.
> >
> >   > > Are you envisioning that users would bind some of these functions
> >   > > to keys themselves?
> >
> >   > Yes. This is the main use-case I envisioned.
> >
> > This is not outright unreasonable.  I still doubt they would
> > interest many users, and I would not favor documenting these
> > features fully in the Emacs Manual.
>
> After some more thinking, I came to the conclusion that I can only
> support adding these new commands if they would work in a much more
> predictable fashion: always move forward/back by ARG sexps and set the
> region on all the sexps they moved across.  IOW, no change in behavior
> depending on whether transient-mark-mode is ON or OFF, no change in
> behavior depending on whether the region is active or not, and no
> confusing notion of "extending the region" lumped into them.
>
> Adding such simple commands could cater to those users who want
> predictable marking behavior; perhaps those user will also want to
> rebind C-M-f and C-M-b to these new commands.
>
> But adding new commands that still change behavior in mysterious ways
> depending on transient-mark-mode and active region is not something I
> would like to do.
>
> Sorry for bringing this up so late, I probably should have said this
> at the very beginning of this discussion, if I were thinking fast
> enough to realize this back then.
>

[-- Attachment #2: Type: text/html, Size: 4088 bytes --]

  reply	other threads:[~2023-05-31  3:23 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 [this message]
2023-05-31 12:01                           ` Eli Zaretskii
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='CAFXT+RPQPxx4mQBFYhqdScUaynQ5oWxL+pzZkG4k2Ba=26=WRA@mail.gmail.com' \
    --to=zkanfer@gmail.com \
    --cc=62892@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    --cc=ruijie@netyu.xyz \
    /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).