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: Sun, 21 May 2023 01:46:21 -0400 Message-ID: References: <86jzxwuedr.fsf@mail.linkov.net> <83o7miw2qk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000208c0a05fc2dad10" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25033"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ruijie@netyu.xyz, 62892@debbugs.gnu.org, monnier@iro.umontreal.ca, drew.adams@oracle.com, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 21 07:47: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 1q0buW-0006K5-V7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 May 2023 07:47:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q0buK-0005me-8a; Sun, 21 May 2023 01:47: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 1q0buI-0005mU-4v for bug-gnu-emacs@gnu.org; Sun, 21 May 2023 01:47: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 1q0buH-0003eJ-Sq for bug-gnu-emacs@gnu.org; Sun, 21 May 2023 01:47:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q0buH-0005yU-OJ for bug-gnu-emacs@gnu.org; Sun, 21 May 2023 01:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Zachary Kanfer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 May 2023 05:47:01 +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.168464800022939 (code B ref 62892); Sun, 21 May 2023 05:47:01 +0000 Original-Received: (at 62892) by debbugs.gnu.org; 21 May 2023 05:46:40 +0000 Original-Received: from localhost ([127.0.0.1]:59864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q0btw-0005xu-1n for submit@debbugs.gnu.org; Sun, 21 May 2023 01:46:40 -0400 Original-Received: from mail-ot1-f45.google.com ([209.85.210.45]:52380) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q0btt-0005xh-U9 for 62892@debbugs.gnu.org; Sun, 21 May 2023 01:46:38 -0400 Original-Received: by mail-ot1-f45.google.com with SMTP id 46e09a7af769-6af6fe73f11so311094a34.0 for <62892@debbugs.gnu.org>; Sat, 20 May 2023 22:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684647992; x=1687239992; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x9ogGORWlVoc8rwW3niGqYCfb9jIm4+mzJWH3LCegxA=; b=EF0LvaPlPttwvQjZr7Kc6YYPkT4TdVzc4gTjimBOEK+HnEekMXQVuquJlq6UXQo741 FfHxZghHYnu5631REklxeO15GPWc+SVbd4UqRMc7KeT6bSkicmQnnNBE7UjURwEYUp4A /cydTiKvm9CBKgKWAhGrlyrcAsVQJtObuj8Dm3FRFbtFmuPvQbVPX3YCi8dSUfLFL4BU GmKGSGrmMuNDL7SfBghFIa8KSiaRF1rWP0xZviSUB2vaI9ggxQLUavtgOLK2yhWigjXs 4pQYqf4KDnOmby1xsy5gusTXrfpEoRWCSKRDWp91+VomfZIEAFqU6oHditudm4V58oOk 2pGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684647992; x=1687239992; 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=x9ogGORWlVoc8rwW3niGqYCfb9jIm4+mzJWH3LCegxA=; b=a3V4kIcFIuFtKWXwhHtKlVAMpxULJH8xPJVXbCQBHeAd06S65PAjv4ZBn4oCmzSTQs DZeGQr6PG2ji1z5ycwTkp1C2I2f4CXbLZi7NyR8b4MmeNZvC/QyWV/mTQYVRglBY32YF lfLbkpRshPcf8Oz3euJzR/qaX8rvUtihn712u62MWD8ZgRX2mCMyUanXqweiiFBacQlp klJ6C6e7JtQmjwYi8MXiI1ocUryOdHi7ES/c1AAoQ90E0LevSK4Prplsin1mdADEdTpa 7+py6MEqjCPcCzbd2dhOUXb+zkeS++fPEnDetStyPu6CQMwHELej0Kfv3ZZuKeWuTiyt wQcA== X-Gm-Message-State: AC+VfDwL1L0xzn1NMAa9fe33rTeoujGHFgVoal3jFjJ2nSVxL+JtBp/E zN3GtXY1aqoaseQYbv5URwLnOgfhkmH8UYIympA= X-Google-Smtp-Source: ACHHUZ4tkhG32gGi18nsLzCF3FMHM0q15eJ9gMpy52EzyCQ3NxqgBgqLNFxMbCiHakmag0UInagR56ldQa9FKELCFtw= X-Received: by 2002:a05:6808:4da:b0:396:33a9:1e0b with SMTP id a26-20020a05680804da00b0039633a91e0bmr3676484oie.34.1684647991870; Sat, 20 May 2023 22:46:31 -0700 (PDT) In-Reply-To: <83o7miw2qk.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:262082 Archived-At: --000000000000208c0a05fc2dad10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think I've made as good an argument as I'm going to. It basically boils down to: * if the keys are bound, it's quicker to call mark-foo-forward and then mark-foo-backward than to call mark-foo, then exchange-point-and-mark, then mark-foo again. * This behavior is simpler and more predictable: mark-foo-forward always marks forward. mark-foo sometimes marks forward and sometimes backwards. The complexity of the various mark-foo functions can be seen in how many cases the docstring has. The behavior of the mark-foo-forward, mark-foo-backward functions can be gathered from the name, without reading the docstrings. I understand we have different opinions, so if this isn't convincing, I'll bow out here. Thanks. On Thu, May 18, 2023 at 2:52=E2=80=AFAM Eli Zaretskii wrote: > > Cc: Ruijie Yu , Stefan Monnier < > monnier@iro.umontreal.ca>, > > "62892@debbugs.gnu.org" <62892@debbugs.gnu.org>, Juri Linkov < > juri@linkov.net> > > From: Zachary Kanfer > > Date: Wed, 17 May 2023 23:17:01 -0400 > > > > Is there anything I can do to make this patch easier to evaluate? As fa= r > as I'm aware, I've addressed > > all comments that have been made in this thread. > > My POV is still as it was before: I'm not sure we should add these new > commands, since the existing commands already provide this > functionality, if you use "C-x C-x" to switch the direction. > > I've seen nothing in the discussion which made me change my mind. Did > I overlook some convincing arguments? > --000000000000208c0a05fc2dad10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think I've made as good an argument as I'm = going to. It basically boils down to:

* if the= keys are bound, it's quicker to call mark-foo-forward and then mark-fo= o-backward than to call mark-foo, then exchange-point-and-mark, then mark-f= oo again.
* This behavior is simpler and more predictable: mark-f= oo-forward always marks forward. mark-foo sometimes marks forward and somet= imes backwards. The complexity of the various mark-foo functions can be see= n in how many cases the docstring has. The behavior of the mark-foo-forward= , mark-foo-backward functions can be gathered from the name, without readin= g the docstrings.

I understand we have differe= nt opinions, so if this isn't convincing, I'll bow out here. Thanks= .

On Thu, May 18, 2023 at 2:52=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
> Cc: Ruijie Yu <ruijie@netyu.xyz>, Stefan Mo= nnier <mon= nier@iro.umontreal.ca>,
>=C2=A0 "62892@debbugs.gnu.org" <62892@debbugs.gnu.org>, Juri Linkov <juri@linkov.net>
> From: Zachary Kanfer <zkanfer@gmail.com>
> Date: Wed, 17 May 2023 23:17:01 -0400
>
> Is there anything I can do to make this patch easier to evaluate? As f= ar as I'm aware, I've addressed
> all comments that have been made in this thread.

My POV is still as it was before: I'm not sure we should add these new<= br> commands, since the existing commands already provide this
functionality, if you use "C-x C-x" to switch the direction.

I've seen nothing in the discussion which made me change my mind.=C2=A0= Did
I overlook some convincing arguments?
--000000000000208c0a05fc2dad10--