From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Zachary Kanfer Newsgroups: gmane.emacs.bugs Subject: bug#62892: proposal to extend mark-sexp to go forward and backward on command Date: Tue, 30 May 2023 23:23:13 -0400 Message-ID: References: <86jzxwuedr.fsf@mail.linkov.net> <83ttvzlj88.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b604ec05fcf4d748" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9599"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, juri@linkov.net, ruijie@netyu.xyz, 62892@debbugs.gnu.org, drew.adams@oracle.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 31 05:24:17 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q4CRd-0002IN-3H for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 31 May 2023 05:24:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4CRQ-0003OX-3x; Tue, 30 May 2023 23:24:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4CRO-0003OJ-GR for bug-gnu-emacs@gnu.org; Tue, 30 May 2023 23:24:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q4CRO-0007WK-8W for bug-gnu-emacs@gnu.org; Tue, 30 May 2023 23:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q4CRO-0006VQ-3y for bug-gnu-emacs@gnu.org; Tue, 30 May 2023 23:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Zachary Kanfer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 31 May 2023 03:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62892 X-GNU-PR-Package: emacs Original-Received: via spool by 62892-submit@debbugs.gnu.org id=B62892.168550341324972 (code B ref 62892); Wed, 31 May 2023 03:24:02 +0000 Original-Received: (at 62892) by debbugs.gnu.org; 31 May 2023 03:23:33 +0000 Original-Received: from localhost ([127.0.0.1]:34572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4CQu-0006Uh-Tw for submit@debbugs.gnu.org; Tue, 30 May 2023 23:23:33 -0400 Original-Received: from mail-oo1-f46.google.com ([209.85.161.46]:49591) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4CQs-0006US-Hb for 62892@debbugs.gnu.org; Tue, 30 May 2023 23:23:31 -0400 Original-Received: by mail-oo1-f46.google.com with SMTP id 006d021491bc7-546ee6030e5so2643145eaf.3 for <62892@debbugs.gnu.org>; Tue, 30 May 2023 20:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685503405; x=1688095405; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GIa1RiWqk5gwtmddxvc6hUI3jgCoMGqCqtJ2TqifKQc=; b=LfhzyOmUwf/J/kaZOdieIzi1XnmvI6JAQ9w5k34YX4YkGgaQOb7V2y0lA7Ny3mZNut IsVId+zCYCjpumwbC2/g5xPMoVv+QjBUTjR/LunFn4vre/nBpnVkv1Mt5sM0VMRwialB U+fJp5QUlur6PblNC3iPyTJ2WnHh9E25PxzzOIyX5pk1Spw8Tgaa6j2/AQxcrp3wQleK 64E35zfrbtJAmoX2pgvM+l/SslX/+D3p0p3Svgtg+bLsGBqDsjwTlGOrj53ik6Mdr+uU LJDz+wl/AJAfWK5ypqFYUYIqOaP65k//a1VZALsEivwS0EGYn29mvLsbrGPDunAhNWGX PGWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685503405; x=1688095405; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GIa1RiWqk5gwtmddxvc6hUI3jgCoMGqCqtJ2TqifKQc=; b=LOETYTSgbpG3qtiLARe9zDPnaAk5GGy+jLmXJBchiPegK+pVDvfFOXfBbk0wOrrlAk AiO5UA7zHylFbRbtkN7AwDOROPBbJ1b95QOLuvJmio3fhE7f5SahkFxTHuT84Ezk8nCf QbmM9kcd1Z7O11k1F/rIatV6p8dbYAaXzYIJg714jKDex8tSEdFAwe93GI7N3izVpBCI uqS2j4M3D7HChix/wwaHS/Yu4dzi0LQHhf2JOeYUBmYIwXH4TfuwjjOWsR+ZJCXwfp9L qwWKtxQJcqBPUXngF4XNb1YumlgDnT9QtVedY6s06lfKtXAojQY/zb/OC1uPbje8SI4A eq9A== X-Gm-Message-State: AC+VfDzZgauJ0vktNKeRC7PtTpbl5U63TLopeNnq0D3ZGU4ylSXBxZem P684BFpxGL45rdOSTibfgu8VClAdnESH3lCE6v0= X-Google-Smtp-Source: ACHHUZ5QpsidsxCZPuKc1NFYwsA/HEvLyag2UDalRSHbbfr/YwTvyusHrqpKUcD/Lr2M03hvRtBkc1891YN2Xjnw5qA= X-Received: by 2002:a4a:41c5:0:b0:555:33cd:cd76 with SMTP id x188-20020a4a41c5000000b0055533cdcd76mr1864454ooa.2.1685503404801; Tue, 30 May 2023 20:23:24 -0700 (PDT) In-Reply-To: <83ttvzlj88.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:262645 Archived-At: --000000000000b604ec05fcf4d748 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Eli Zaretskii wrote: > > Cc: ruijie@netyu.xyz, 62892@debbugs.gnu.org, monnier@iro.umontreal.ca, > > drew.adams@oracle.com, juri@linkov.net > > From: Richard Stallman > > 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. > --000000000000b604ec05fcf4d748 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is interesting. Let me see if I'm understand= ing properly. In this, I'll talk only about sexps, but I believe this a= rgument should apply to all the forms we've talked about (word, sexp, p= aragraph, defun, page). These commands should:

1. Always move forward/back by ARG sexps (defaulting to 1), setting the re= gion 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 e= nabled.
3. Don't change behavior if the region is active or n= ot.

#2 and #3 I believe can be considered together= . There are a few things that could do this, but I think what you're sa= ying is that this function should *only* move mark. That is, point should s= tay the same no matter what is called here. Additionally, it should activat= e mark. Is that what you meant?

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

My understanding was that #'use-reg= ion-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 accu= rate?


On Fri, May 26, 2023 at 2:06=E2=80=AFAM Eli Z= aretskii <eliz@gnu.org= > wrote:
= > Cc: ruijie@netyu= .xyz, 62892@= debbugs.gnu.org, monnier@iro.umontreal.ca,
>=C2=A0 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 en= ough
> to be worth thinking about.
>
>=C2=A0 =C2=A0> > Are you envisioning that users would bind some o= f these functions
>=C2=A0 =C2=A0> > to keys themselves?
>
>=C2=A0 =C2=A0> Yes. This is the main use-case I envisioned.
>
> This is not outright unreasonable.=C2=A0 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.=C2=A0 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.
--000000000000b604ec05fcf4d748--