[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Python interactive navigation around nested functions
From: |
Dima Kogan |
Subject: |
Re: Python interactive navigation around nested functions |
Date: |
Fri, 24 Jun 2016 15:10:51 -0700 |
User-agent: |
mu4e 0.9.17; emacs 25.0.94.1 |
Stefan Monnier <address@hidden> writes:
>> 2. If we're NOT on a function-definition line, C-M-a should go up to the
>> previous definition, at a HIGHER AST level.
>
> That's a significant change. It means that if we're between two
> functions (e.g. on a static var declaration in a C file), C-M-a would
> jump to BOB.
Hi. So to be clear, my thinking here is about getting do-what-I-mean
behavior out of C-M-a.
The current implementation in emacs already has special-case behavior if
no leading block-start is found: instead of going to BOB, the point is
left where it is. The proposal could be modified slightly to
special-case it differently, and try to go to the prev-defun-start at
the same-or-higher level, which would produce the current behavior in
this case.
Here's a case where the current behavior is not what the user wants (at
least never what I want). Say you have this:
defun f1():
# stuff
defun f2():
# stuff
# stuff
# stuff
# lots and lots of stuff
# So much stuff that when I'm here I know I'm in f1(), but f2 isn't
# something i'm thinking about at all
If I C-M-a, at the end of f1(), I, the human editing this source am
thinking about f1(), but not thinking about f1() at all, and I want to
go to the start of f1(). I could hit C-M-u instead, but that will stop
at any if/while/etc blocks.
The behavior the feels "right" is implemented here:
https://github.com/dkogan/emacs-snapshot/blob/python_indent/lisp/progmodes/python.el
There're a few more fixes in that tree that I'll submit separately in a
bit.
> Of course by C-M-a we can mean different things:
> - the backend navigation code provided by the major mode via
> *-of-defun-function.
> - the command bound to C-M-a.
> - the beginning-of-defun command.
>
> They don't do exactly the same thing either, and the constraints w.r.t
> changing them are slightly different (e.g. some allow the introduction
> of a whole new backend API, or the rebinding of C-M-a to another command).
Yeah, I'd rather not proliferate multiple similar-yet-slightly-different
behaviors, so I'll simply use my own python nav functions in my work if
this gets rejected.
Thanks
dima
Re: Python interactive navigation around nested functions, Dima Kogan, 2016/06/21
- Re: Python interactive navigation around nested functions, Dima Kogan, 2016/06/21
- Re: Python interactive navigation around nested functions, Stefan Monnier, 2016/06/21
- Re: Python interactive navigation around nested functions,
Dima Kogan <=
- Re: Python interactive navigation around nested functions, Clément Pit--Claudel, 2016/06/24
- Re: Python interactive navigation around nested functions, Andreas Röhler, 2016/06/26
- Re: Python interactive navigation around nested functions, Clément Pit--Claudel, 2016/06/26
- Re: Python interactive navigation around nested functions, Andreas Röhler, 2016/06/27
Re: Python interactive navigation around nested functions, Stefan Monnier, 2016/06/24
Re: Python interactive navigation around nested functions, Andreas Röhler, 2016/06/26
Re: Python interactive navigation around nested functions, Andreas Röhler, 2016/06/21
Re: Python interactive navigation around nested functions, Andreas Röhler, 2016/06/21