all messages for Emacs-related lists mirrored at yhetil.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; 11+ 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] 11+ messages in thread
end of thread, other threads:[~2021-07-31 16:44 UTC | newest]

Thread overview: 11+ 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 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

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.