[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56135: 29.0.50; python.el - forward-sexp regression over triple-quot
From: |
Kévin Le Gouguec |
Subject: |
bug#56135: 29.0.50; python.el - forward-sexp regression over triple-quoted strings |
Date: |
Thu, 23 Jun 2022 08:49:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
João Távora <joaotavora@gmail.com> writes:
> On Wed, Jun 22, 2022 at 10:48 PM Kévin Le Gouguec <kevin.legouguec@gmail.com>
> wrote:
>
> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
> > João Távora <joaotavora@gmail.com> writes:
> >
> >> Why are you setting python-forward-sexp-function to nil?
> >
> > [wall of text follows]
>
> (
> Hadn't realized we had taken this off-list. FWIW if you found all
> my verbiage informative, don't hesitate to (tell me to) forward it
> back on the bug tracker.
> )
>
> Ups. That was my mistake. Wondering what to do now. Should we re-send to
> the
> tracker. Or let future generations wonder about the missing great wall of
> text.
😁 I'll forward it in a separate message, in case someone finds other
points to bounce off of.
> Anyway, I did find your wall of text informative, particularly this point.
>
>> 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"?
>
> Yes, I think this makes sense. Let's see what other think, but a patch
> that extracts only that bit from the current functionality and puts it in
> a third value would be a good idea, I think.
Mm. I've stepped through python-nav--forward-sexp with Edebug, and
there wasn't any obvious "triple-quote handler" to extract. IIUC
* being on either end of a triple-quote block satisfies
python-info-{beginning,end}-of-statement-p, so 'context' becomes
'statement-{start,end},
* (then we dance a little gigue to compute next-sexp-{context,pos},
which we do not end up using in this scenario,)
* eventually we call python-nav-{end,beginning}-of-statement.
So the "magic" happens in those functions IIUC. E.g. in
python-nav-end-of-statement we either
* skip the whole cond form because the initial (goto-char
(line-end-position)) took us at EOL after a single-line string, or…
* go down the (setq string-start (python-syntax-context 'string)) path
for multiline strings, or…
* … oh! Mm, well, here's a bug maybe? Consider:
"""string 1"""
def foo():
"""string 2
(multiline).
"""
print("""string 3""")
^
So *with python-forward-sexp-function set to its default value*
(python-nav-forward-sexp), with point on the ^ mark (at the beginning of
"""string 3"""),
* before commit 0646c68, C-M-f moved to the end of """string 3""",
* now it just moves over one pair of quotes.
(Feel like I should note that single-line triple-quoted strings have
their uses FWIW, since they let one write single and double quotes into
the string without the need to backslash-escape them)
I see that the new commentary in python-syntax-stringify addresses this,
I guess?
> ;; FIXME: This makes sexp-movement a bit suboptimal since """a"""
> ;; is now treated as 3 strings.
So AFAICT while the change meant to improve the situation with
electric-pair-mode (which I'm grateful for, since I'm a happy user of
that minor mode), it did make sexp-movement a bit more "janky" (meaning
"hard to predict and rely on", no offense meant), *regardless* of
whether users (un)set (python-)forward-sexp-function 😕