From: Stefan Kangas <stefan@marxist.se>
To: "João Távora" <joaotavora@gmail.com>
Cc: 41361@debbugs.gnu.org, immerrr@gmail.com,
"Andreas Röhler" <andreas.roehler@online.de>
Subject: bug#41361: Fwd: Re: python.el: improve sexp-based navigation or make it optional?
Date: Fri, 19 Mar 2021 21:51:52 -0500 [thread overview]
Message-ID: <CADwFkmkfAfbq+qrc0DG+yozyix13_T9c4wu9b2UrG=_xoP4Dpg@mail.gmail.com> (raw)
In-Reply-To: <87y2pl2ylw.fsf@gmail.com> ("João Távora"'s message of "Thu, 21 May 2020 14:42:35 +0100")
João Távora <joaotavora@gmail.com> writes:
> Stefan Kangas <stefan@marxist.se> writes:
>
>> Andreas Röhler <andreas.roehler@online.de> writes:
>>
>>> maybe make forward-sexp-function customizable. Currently that var is
>>> set inside the derived mode:
>>
>> I agree that this should be customizable.
>
> I too am a fan of sexp navigation (C-M-f, C-M-b, etc.) If this
> navigation in indeed superior, we could consider making it the default
> for python-mode? Something similar thing was done recently for
> nxml-mode, by changing nxml-sexp-element-flag from nil to t. I liked
> this change very much.
I have been back to coding a bunch of Python lately, and having
experimented with this I think making it the default behavior is indeed
a good idea.
In the linked emacs-devel thread, I said that the old behavior was fine,
which I guess is true. I have now come to the conclusion that it is
also worse than the alternative. :-)
next prev parent reply other threads:[~2021-03-20 2:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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='CADwFkmkfAfbq+qrc0DG+yozyix13_T9c4wu9b2UrG=_xoP4Dpg@mail.gmail.com' \
--to=stefan@marxist.se \
--cc=41361@debbugs.gnu.org \
--cc=andreas.roehler@online.de \
--cc=immerrr@gmail.com \
--cc=joaotavora@gmail.com \
/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.