all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: immerrr again <immerrr@gmail.com>
To: emacs-devel <emacs-devel@gnu.org>
Subject: python.el: improve sexp-based navigation or make it optional?
Date: Sat, 16 May 2020 15:16:44 +0200	[thread overview]
Message-ID: <CAERznn-xfkqZUjP48u7Uw87yjvEcjL2fGU5UunJfjBcAN_SoGA@mail.gmail.com> (raw)

Hi everyone,

I'm a frequent user of python.el, and I have a qualm about its "smart"
sexp navigation. As a long-time Emacs user, I have come to certain
expectations about how Emacs behaves, and I cannot wrap my hand around
some of the idiosyncrasies there.

Below you can find a couple of examples. Where forward-sexp from 1
takes point to 2, and backward-sexp from 2 takes point back to 1.

A.
<1>x = 'foo'<2>

B.
<1>class Test:
    X = 'foo'
    Y = 'bar'<2>

C.
<1>def calc_foo(...):
    ...<X lines of code>
    return foo<2>

It seems logical to be able to skip an entire statement, or an entire
defun/defclass, but what if I want to go select just the last literal
in a statement? The problem here is that there is no way to
unambiguously tell python-mode what symbol/literal/block do I want to
skip. To clarify, let's pretend Python had parentheses around its
syntactical blocks:

<1>(<2>def<2'> my_func(x):
    <3>(if (x == 'foo'):
        <4>(Y = <5>'bar'<5'>)<4'>)<3'>)<1'>

In this case it's easy to predict that forward/backward-sexp should
establish the following pairs: 1 with 1', 2 with 2', 3 with 3' and so
on. But without the parentheses, there is no way to distinguish
between 1 and 2, or between 1', 3', 4', and 5'. Python.el essentially
tries to make a guess, and curiously, this explicitly goes against one
of the principles listed in the Zen of Python,

> In the face of ambiguity, refuse the temptation to guess.

Some kind of a visual-sexp mode for this type of navigation would
reduce the uncertainty. A mode that would augment the code with some
kind of an overlay, showing parentheses around each sexp composed of
more than 1 symbol/literal, and provide visual guidance as to where
will point end up after a sexp-based navigation command. However, IIRC
overlays don't scale well, and it might require implementing yet
another parser or hacking all the structural information to the
pre-existing one, which is a quite tedious task.

In absence of such mode, I wonder if it would be a welcome addition to
introduce a configuration parameter that at least disables the smart
navigation, making sexp skip one symbol or explicitly
parenthesized/bracketed expression at a time.

What do you think?



             reply	other threads:[~2020-05-16 13:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-16 13:16 immerrr again [this message]
2020-05-16 14:05 ` python.el: improve sexp-based navigation or make it optional? Stefan Kangas
2020-05-16 19:11 ` Andreas Röhler
2020-05-16 20:46   ` immerrr again
2020-05-17 14:12   ` bug#41361: Fwd: " Andreas Röhler
2020-05-20  1:06     ` Stefan Kangas
2020-05-21 13:42       ` João Távora
2021-03-20  2:51         ` Stefan Kangas
2021-07-31 16:44     ` Lars Ingebrigtsen
2020-05-17  3:04 ` Stefan Monnier
2020-05-20  1:06 ` Stefan Kangas

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAERznn-xfkqZUjP48u7Uw87yjvEcjL2fGU5UunJfjBcAN_SoGA@mail.gmail.com \
    --to=immerrr@gmail.com \
    --cc=emacs-devel@gnu.org \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.