GNU bug report logs - #13642
24.3.50; python-nav-backward-sexp mishandles string movement

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13642 in the body.
You can then email your comments to 13642 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Schaefer <forcer <at> forcix.cx>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; python-nav-backward-sexp mishandles string movement
Date: Thu, 07 Feb 2013 00:50:46 +0100

Hello!
In python-mode, I get the following behavior (with _|_ being point):

-----
def foo():
    bar = "bar"
    baz = "baz"_|_

=>

_|_def foo():
    bar = "bar"
    baz = "baz"
-----

I would have expected point to move to the beginning of the string, not
to the beginning of def.

I also get this:

-----
def foo():
    bar = "bar"_|_
    baz = "baz"

=>

def foo():
    _|_bar = "bar"
    baz = "baz"
-----

Again, I would have expected point to end up in front of the string, not
the beginning of the statement.

python-mode sets forward-sexp-function, so these operations are done
when using C-M-b (and C-M-f), which is very counterintuitive to me.

Regards,
        -- Jorgen

Message #8 received at 13642 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Jorgen Schaefer <forcer <at> forcix.cx>
Cc: 13642 <at> debbugs.gnu.org
Subject: Re: bug#13642: 24.3.50; python-nav-backward-sexp mishandles string
	movement
Date: Wed, 06 Feb 2013 16:12:43 -0800

[Message part 1 (text/plain, inline)]

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.

This functionality appears to be buggy:

def foo():
    bar = "bar"
    baz = "baz"
    x=x()_|_

=>

def foo():
    bar = "bar"
    baz = "baz"
    x=x_|_()

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

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 13642 <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Schaefer <forcer <at> forcix.cx>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 13642 <at> debbugs.gnu.org
Subject: Re: 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 <dancol <at> dancol.org> 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? :-)

Regards,
	-- Jorgen

Message #14 received at 13642 <at> debbugs.gnu.org (full text, mbox):

From: Fabián Ezequiel Gallina <fabian <at> anue.biz>
To: 13642 <at> debbugs.gnu.org
Date: Wed, 13 Feb 2013 21:31:32 -0300

The current behavior follows pretty much what emacs-lisp-mode does for 
lisp movement, so I won't agree calling it weird, It's just a matter of 
taste. If setting the `forward-sexp-function' to nil fits your needs 
then feel free to do so. I'll add documentation in the header explaining 
how to disable such behavior.

The paren thing at end of defun Daniel found is a known cornercase, 
which unfortunately I can't fix because `blink-matching-open' needs 
`python-nav-forward-sexp' to behave this way to work correctly.

Also notice this is not a whimsical feature, it was in fact a feature 
request[0] by another user. And I honestly find it pretty cool overall.


[0] https://github.com/fgallina/python.el/issues/106



Regards,
Fabián.

Message #17 received at 13642 <at> debbugs.gnu.org (full text, mbox):

From: Fabián Ezequiel Gallina <fabian <at> anue.biz>
To: 13642 <at> debbugs.gnu.org
Date: Wed, 13 Feb 2013 21:47:53 -0300

I added documentation how to disable this behavior in the header.

I also changed the behavior when inside strings/comments to follow the 
emacs-lisp-mode behavior.

All this in revno 111261.


Regards,
Fabián.

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#13642: 24.3.50; python-nav-backward-sexp mishandles string
	movement
Date: Wed, 15 May 2013 07:55:51 +0200

Am 07.02.2013 01:12, schrieb Daniel Colascione:
> 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.
>
> This functionality appears to be buggy:
>
> def foo():
>      bar = "bar"
>      baz = "baz"
>      x=x()_|_
>
> =>
>
> def foo():
>      bar = "bar"
>      baz = "baz"
>      x=x_|_()
>
> I also find the behavior more counter-intuitive than useful, and I wish
> python-mode acted more like cc-mode here.
>


[ ... ]

hmm, din't think so. In Python that point indicates the end of assignment
baz = "baz"

End of defun is reached with following dedent only.

So the OP's expection seems wrong too:

backward-sexp must reach the beginning of the assigment "baz =..."

BTW in python-mode.el we have py-beginning-of-expression for the OP's want.

Cheers,

Andreas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.