unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* python.el: improve sexp-based navigation or make it optional?
@ 2020-05-16 13:16 immerrr again
  2020-05-16 14:05 ` Stefan Kangas
                   ` (3 more replies)
  0 siblings, 4 replies; 6+ messages in thread
From: immerrr again @ 2020-05-16 13:16 UTC (permalink / raw)
  To: emacs-devel

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?



^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-20  1:06 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-05-16 13:16 python.el: improve sexp-based navigation or make it optional? immerrr again
2020-05-16 14:05 ` Stefan Kangas
2020-05-16 19:11 ` Andreas Röhler
2020-05-16 20:46   ` immerrr again
2020-05-17  3:04 ` Stefan Monnier
2020-05-20  1:06 ` Stefan Kangas

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).