all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ivan Andrus <darthandrus@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 11974@debbugs.gnu.org
Subject: bug#11974: 24.1.50; python-nav-forward-sexp-function doesn't skip over strings
Date: Thu, 19 Jul 2012 21:40:59 +0200	[thread overview]
Message-ID: <EB183215-56A7-48CA-B1F5-8CC6B380560B@gmail.com> (raw)
In-Reply-To: <jwvliigw6e3.fsf-monnier+emacs@gnu.org>

Oops, forgot to cc the buglist.

On Jul 19, 2012, at 9:52 AM, Stefan Monnier wrote:

>> (let* ((bos (python-info-ppss-context 'string)))
>> (goto-char bos)
>> (forward-sexp 1)
>> (narrow-to-region bos (point)))
> 
>> This is broken now since forward-sexp goes to the end of the block, far
>> past the end of the string (or not moving at all).  If you have any
>> undindented code at the end of your buffer, then forward-sexp (and up-list)
>> will refuse to move past it e.g.
> 
> There's a similar problem in SMIE's implementation of forward-sexp.
> Basically, the issue is that there are several "sexp"s that start at
> point and forward-sexp has to choose which one to skip over.
> Every choice is valid, but since there's no way for the user to say
> which choice she wants, any choice is bound to disappoint and/or
> surprise the user sometimes.

I didn't realize SMIE implemented forward-sexp.  Yet another reason for me to use it.

> That doesn't mean that it's a hopeless problem and that we shouldn't try
> to improve the behavior, tho: in practice (maybe just for historical
> reasons), I find that I generally prefer "the smallest sexp", especially
> since I can repeat forward-sexp if it didn't skip enough.

I agree.  The smallest is usually best.

> I.e. Python's forward-sexp should only try to skip over
> indentation-delimited blocks when it has a clear indication that only
> skipping the current line/statement would be wrong, or that there's an
> easy/intuitive way for the user to get the other behavior (e.g. by
> starting the forward-sexp from elsewhere).
> 
> For example, with SMIE if I have
>  a + b * c
> and I'm before "b", forward-sexp will only skip over "b", but if I move
> to just before the "+", then forward-sexp will skip to after "c".
> I'm not sure if Python's indentation-delimited blocks can find a similar
> "convention" for the user to express her intention.
> 
>> What I would expect form a "perfect" python forward-sexp is to skip over
>> a block if and only if you are at the very beginning of the block.
> 
> You mean that forward-sexp would generally skip over just a statement,
> except if it's the first statement of a block in which case it skips the
> whole block?  That sounds a bit arbitrary, making it difficult for the
> user to skip over just the first statement.

No, it would only skip over a block if it's at the block opening.  In some sense the entire block is one statement hence my thinking.  See below.

> [ Bear in mind, I never write Python.  ]
> How 'bout
> 
> def foo():
>     toto
>     bar
> 
> if I'm before `toto' on the same line, forward-sexp should skip over
> "toto", but if I'm right after the ":" (and before the \n) then
> forward-sexp should skip to after "bar".

In my mind you should skip to after bar only if the cursor is before the def (or possibly anywhere in the def keyword).  If I'm anywhere after that I consider myself to be "inside" the block.  But that's only the way I think and may not be representative of other (more serious) python programmers etc. etc.

I guess I would treat both if and else as separate "block openers" rather than if opening a single block.  Maybe an easy rule would be if you are at the beginning of the statement (well between the end of the last and the beginning of the current) go to the next statement that has the same indentation?  Anywhere else do as a "normal" forward-sexp.

-Ivan




  reply	other threads:[~2012-07-19 19:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-18 12:29 bug#11974: 24.1.50; python-nav-forward-sexp-function doesn't skip over strings Ivan Andrus
2012-07-19  7:52 ` Stefan Monnier
2012-07-19 19:40   ` Ivan Andrus [this message]
     [not found]   ` <D3BE0B6C-F35A-4E54-A68C-FAB0F92E30D8@gmail.com>
2012-07-19 22:54     ` Stefan Monnier
2012-09-28 21:18       ` Ivan Andrus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EB183215-56A7-48CA-B1F5-8CC6B380560B@gmail.com \
    --to=darthandrus@gmail.com \
    --cc=11974@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.