[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13642: 24.3.50; python-nav-backward-sexp mishandles string movement

From: Jorgen Schaefer
Subject: bug#13642: 24.3.50; python-nav-backward-sexp mishandles string movement
Date: Fri, 8 Feb 2013 22:27:57 +0100

On Wed, 06 Feb 2013 16:12:43 -0800
Daniel Colascione <address@hidden> wrote:

> On 2/6/2013 3:50 PM, Jorgen Schaefer wrote:
> > Hello!
> > In python-mode, I get the following behavior (with _|_ being point):
> > 
> > -----
> > def foo():
> >     bar = "bar"
> >     baz = "baz"_|_
> > 
> > =>
> > 
> > _|_def foo():
> >     bar = "bar"
> >     baz = "baz"
> > -----
> That's by design. python-mode tries to emulate lisp movement as much
> as possible, so it considers point to be at the end of a "defun" and
> tries to skip over the entire "defun", back to the beginning.

It would seem that it would make sense to assume the point is at the
end of the block only if it's *past* the last line of the block, not
while it's still on it.

> I also find the behavior more counter-intuitive than useful, and I
> wish python-mode acted more like cc-mode here.

cc-mode simply leaves `forward-sexp-function' nil. Setting that to nil
in python-mode-hook makes python-mode behave "intuitively" for me
again. I have no idea under which circumstances this is useful. There's
C-M-a to go to the beginning of a defun if I want to, and python.el
could bind python-nav-backward/forward-statement to M-a and M-e which
would make a lot of sense.

The current behavior is just ... weird.

Who is the person to decide that this should change? :-)

        -- Jorgen

reply via email to

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