From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Newsgroups: gmane.emacs.bugs Subject: bug#56135: =?UTF-8?Q?[K=C3=A9vin?= Le Gouguec] Re: bug#56135: 29.0.50; python.el - forward-sexp regression over triple-quoted strings Date: Thu, 23 Jun 2022 08:53:41 +0200 Message-ID: <87bkuj27m2.fsf@gmail.com> References: <875yktgpiz.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26855"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: 56135@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 23 08:54:38 2022 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 1o4Gje-0006q9-AU for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 08:54:38 +0200 Original-Received: from localhost ([::1]:54304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4Gjd-0007f6-9d for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 02:54:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45212) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Gj7-0007cC-7D for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 02:54:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43187) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4Gj4-0006KO-F9 for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 02:54:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o4Gj4-0004c6-DF for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 02:54:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <875yktgpiz.fsf@gmail.com> Resent-From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Jun 2022 06:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56135 X-GNU-PR-Package: emacs Original-Received: via spool by 56135-submit@debbugs.gnu.org id=B56135.165596723217713 (code B ref 56135); Thu, 23 Jun 2022 06:54:02 +0000 Original-Received: (at 56135) by debbugs.gnu.org; 23 Jun 2022 06:53:52 +0000 Original-Received: from localhost ([127.0.0.1]:37084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4Git-0004bb-QC for submit@debbugs.gnu.org; Thu, 23 Jun 2022 02:53:52 -0400 Original-Received: from mail-wm1-f52.google.com ([209.85.128.52]:53761) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4Giq-0004bM-Jn for 56135@debbugs.gnu.org; Thu, 23 Jun 2022 02:53:50 -0400 Original-Received: by mail-wm1-f52.google.com with SMTP id z9so10434893wmf.3 for <56135@debbugs.gnu.org>; Wed, 22 Jun 2022 23:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding; bh=GXvJHKyAJB+ReLW2CpAExBHcdQe1B9z3H5xgiVZcr20=; b=I14rITXpVUUJEGiFRjwq7iegGaQFi8uLAsnDNICyyy6mLuuymTRAXzO/b1EvUaIvRm OD3qWQ0IAvWD/ZEMjQeKutdglQcECgulxO1vmEvNfqYjeceCj1vu4V/YZlwpPMfa4JB2 NIfLqekeO+DV8NSdDkJIVf9kP3IimQaLxYsDz0YN6DakCPfz5qXCbnKiYTBd5MXAL/xV Qw10kd7flLfaxawjxll8ulO3EcNAtAxlmj4fOiZ8h2qzf6JeSj89oIRI939pn5boVr4e V/Xt1A5PQwsRfY7UWCm1JQfz6xa91TGNhhfI8GGFjDyDccLKtAQH4DQoM5SuQhFBOx2w qkoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version:content-transfer-encoding; bh=GXvJHKyAJB+ReLW2CpAExBHcdQe1B9z3H5xgiVZcr20=; b=I7P9DRzPd8scs102I7bzeKZCdcevcFe5XJ32NT6m+UVH82+GtNcKkGtzxxvMFtCnwZ pTBTJ8bA5LkpVMTPi7pWtu+wnOKPBVtRJYBfi6iH+e++Crl4oO8uc71vXFZSC2xh/M8t vN3+laB6kDkZPPbEb61WcvWOXScCYl1G3f7gkt0IrQRbgM3U69tbtKrqeD2ektytTyUc AfLoNfIWa4qiNw70uBhCEM0px7amzYHzBUxpe/q/+ZpVqSb3V/HAyWiE8f1jXg8tDDJe 0aGhJ5mF7B7wZtQ0DqnV4sBCtJlEPUB727JDkvwAHyIKhtMnWBccrRAX11NlhrR1k4A2 MLTw== X-Gm-Message-State: AJIora95bRVK2CoaFLsPxdI9ACmxLlgpwTddJXN+CzAIY5Jgq2DQruBX SRBfxZsSUPZTjXjklU76Xb5fHYdBEjw= X-Google-Smtp-Source: AGRyM1vrpEHLeo6V4q81rUKc67vVuMSYlvT3hvcPLve8qVNsc6JETCmJjhj/EOtJbTRSJTawVSyJFQ== X-Received: by 2002:a05:600c:286:b0:3a0:30f8:8a43 with SMTP id 6-20020a05600c028600b003a030f88a43mr1562138wmk.90.1655967222598; Wed, 22 Jun 2022 23:53:42 -0700 (PDT) Original-Received: from amdahl30 ([2a01:e0a:253:fe0:2ef0:5dff:fed2:7b49]) by smtp.gmail.com with ESMTPSA id l35-20020a05600c1d2300b0039c95b31e66sm1911419wms.31.2022.06.22.23.53.41 for <56135@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jun 2022 23:53:42 -0700 (PDT) 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" Xref: news.gmane.io gmane.emacs.bugs:235066 Archived-At: (Off-list message that Jo=C3=A3o already replied to in ; re-sent for archival) -------------------- Start of forwarded message -------------------- From: K=C3=A9vin Le Gouguec To: Jo=C3=A3o T=C3=A1vora Cc: Stefan Monnier Subject: Re: bug#56135: 29.0.50; python.el - forward-sexp regression over triple-quoted strings Date: Wed, 22 Jun 2022 22:39:42 +0200 Jo=C3=A3o T=C3=A1vora writes: > On a very superficial analysis, I would say you're _not_ experiencing a=20 > bug, because setting the f-sexp-f to nil buffer-locally would mean > you don't want any python-specific behaviour for triple quotes.=20=20 > > It might be a regression for a previous state of the working tree, but th= en > again that state seems to have been buggy itself, undoubtedly, at least a= s=20 > described by myself in 0646c6817139.=20=20 > > Why are you setting python-forward-sexp-function to nil? The motivation behind that user option (or the commentary suggesting to set forward-sexp-function to nil before the user option existed) is to change how python-mode's *ward-sexp commands behaves wrt blocks. Consider this function: def foo(): return bar_baz(quux, corge) By default, when point is=E2=80=A6 * at the start of "def": C-M-f moves to the end of the function (at the end of "bar_baz(quux, corge)"), * at the end of "bar_baz(quux, corge)": C-M-b moves to the beginning of the function (at the start of "def"). IOW by default python-mode uses sexp commands to move across whole blocks, even when point is on something that might be considered a sexp in other major modes (identifiers, or paired delimiters); I imagine that since Python blocks are based on whitespace rather than explicit delimiters, python-mode tries to be helpful by adding "implicit paired delimiters": (a)[b]def foo():(b) (c)return bar_baz(quux, corge)[c](a) (Read "(x) jumps to the corresponding (x)"; using [y] with square brackets to designate "destination points" for C-M-f/C-M-b that cannot be used as "source" points for C-M-b/C-M-f, since they are shadowed by (x) "source" points in the same spot) Setting (python-)forward-sexp-function to nil was the recommended way to take those implicit paired delimiters out of the equation[1]. So that was the situation before this commit, AFAICT: triple-quote docstrings did not enter the picture and even with forward-sexp-function set to nil, C-M-[bf] did TRT (skipping over them). I can readily believe that things working the way I liked was a happy accident and, on balance, your change fixed more than it broke. Wondering what the best way forward would be. Maybe a third suggested value for python-forward-sexp-function, which would handle triple-quotes but not add those "implicit paired delimiters"? FWIW my impression (from some light Googling) is that setting this option to nil (or the forward-sexp-function variable buffer-locally) is something that a fair number of python-mode users have been doing for years, without worrying about how that would impact docstring navigation. [1] Irrelevant motivation tucked under a footnote: Getting rid of the "implicit paired delimiters" suits me well, since it's easier for me to reason about: * I frequently overshoot my movement and need to hit e.g. a couple of back- commands after a string of forward- commands; python-mode's those invisible pair delimiters make {forward,backward}-sexp no longer cancel each other, which is disorienting; * if point is on a word or a paired delimiter, I expect *ward-sexp to move over that, instead of leaping over a whole block. E.g. when point is on the closing parenthesis of "bar_baz(quux, corge"): if I want to move to the start of "bar_baz", * with "traditional" sexps, it's just two C-M-b away, * with python-mode's default sexps, it's=E2=80=A6 I dunno; M-b C-M-u C-= M-b? M-m M-f C-f? It's frustrating because in any other major mode, I don't need to _stop and think_ about how to solve that puzzle; those invisible pairs force me to hold my fingers, squint and guess their position, then plan my route. I'm sure python-mode's default block movement is useful to some folks; IME I do fine with defun-movement (C-M-[ae]) or python-mode's other block commands (M-[ae]). I get more value out of C-M-[bf] by keeping them limited to identifiers and pairs. -------------------- End of forwarded message --------------------