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

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

[Jorgen Schaefer]

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

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Jorgen Schaefer]

On Wed, 06 Feb 2013 16:12:43 -0800
Daniel Colascione <dancol@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

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

[Andreas Röhler]

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

bug#13642: (no subject)

[Fabián Ezequiel Gallina]

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.

bug#13642: (no subject)

[Fabián Ezequiel Gallina]

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.