[Top][All Lists]

[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

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:


There're a few more fixes in that tree that I'll submit separately in a

> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]