backward-up-list

backward-up-list

[Stephan Stahl]

Hi.

I have found 'backward-up-list' not to work in some major modes when 
point is in a string.

Too repeat the behaviour find the file 'lisp/emacs-lisp/lisp.el'. It 
should start 'emacs-lisp-mode'. Go to line 112. ( This is the actually 
the function 'backward-up-list'. )
Press M-C-u. I get the error message
'up-list: Scan error: "Unbalanced parentheses", 3824, 1'.
Doing the same when text-mode is active works as it should.

So far i have tracked 'backward-up-list' back to the C function
'static Lisp_Object scan_lists (from, count, depth, sexpflag)' in
'src/syntax.c' line 2037 . But i suppose the different behaviour results 
in different parenthese settings for 'text-mode' and 'emacs-lisp-mode'.
But i do not know where to start looking at...

Could someone please help me with this?

Thanks.
Stephan

Re: backward-up-list

[Stefan Monnier]

> I have found 'backward-up-list' not to work in some major modes when 
> point is in a string.

I'd expect it "not to work" in any major-mode.
backward-up-list as well as forward-sexp, backward-sexp, ... all
assume that the starting position is outside of any string and/or comment.
It's non-trivial to fix and sometimes people rely on the current behavior
so even if a technical solution comes around, it might be difficult
to use it because of the incompatible change in behavior.


	Stefan

PS: It "works" in text-mode simply because point cannot be in a string
    since there are no strings (or comments for that matter) in text-mode.

Re: backward-up-list

[Richard Stallman]

backward-up-list has no way of knowing whether point is inside a
string, so it can only make an assumption--that you're not in a list.

Nowadays it may be possible to do better; there may be an efficient
way to tell whether point is in a list.  If so, it would be a good
thing to implement something better.

Stefan, can we determine this efficiently using your newer syntax
parsing features?

Re: backward-up-list

[Henrik Enberg]

Richard Stallman <rms@gnu.org> writes:

> Nowadays it may be possible to do better; there may be an efficient
> way to tell whether point is in a list.  If so, it would be a good
> thing to implement something better.
>
> Stefan, can we determine this efficiently using your newer syntax
> parsing features?

I have been using this little function built atop Stefans syntax
package for turning on flyspell mode in comment and strings.  It
doesn't seem to cause any noticable slowdown.

(defun inside-comment-or-string-p ()
  "Return non-nil if `point' is inside a comment or string."
  (let ((state (syntax-ppss (point))))
    (or (nth 3 state) (nth 4 state))))

-- 
Booting... /vmemacs.el

Re: backward-up-list

[Stefan Monnier]

> I have been using this little function built atop Stefans syntax
> package for turning on flyspell mode in comment and strings.  It
> doesn't seem to cause any noticable slowdown.

BTW, if you use font-lock, it's probably a bit more efficient
to use flyspell-prog-mode (which just relies on font-lock's
faces, which might not always be quite the same info as the
output of syntax-ppss, but I'm not sure which is worse/better).


	Stefan

Re: backward-up-list

[Richard Stallman]

    (defun inside-comment-or-string-p ()
      "Return non-nil if `point' is inside a comment or string."
      (let ((state (syntax-ppss (point))))
	(or (nth 3 state) (nth 4 state))))

Stefan, do you see any reason this would be wrong?
(Depending on font lock would not be a general solution.)

If Stefan sees no basic flaw in this, then would one of you like to
try modifying some of the functions in lisp.el to test this criterion?
I guess backward-up-list could move backward out of the string
constant and treat that as one level of list.  Same-level motion
commands could move to the beginning or end of the string and count
that as having moved over one sexp.

Re: backward-up-list

[Stefan Monnier]

>     (defun inside-comment-or-string-p ()
>       "Return non-nil if `point' is inside a comment or string."
>       (let ((state (syntax-ppss (point))))
> 	(or (nth 3 state) (nth 4 state))))
> 
> Stefan, do you see any reason this would be wrong?

No particular reason, no.

> (Depending on font lock would not be a general solution.)

Indeed.  It's a convenient hack, but no more.

> If Stefan sees no basic flaw in this, then would one of you like to
> try modifying some of the functions in lisp.el to test this criterion?
> I guess backward-up-list could move backward out of the string
> constant and treat that as one level of list.  Same-level motion
> commands could move to the beginning or end of the string and count
> that as having moved over one sexp.

Of course if backward-up-list can work all within the string
(in which it currently already DTRT), it should still DTRT.
So it should first try "within the string/comment" and only if
that fails, should it move out.
I'm sure there are more special cases to think of,


	Stefan

Re: backward-up-list

[Richard Stallman]

    Of course if backward-up-list can work all within the string
    (in which it currently already DTRT), it should still DTRT.

I don't think so.  I think that reliably moving out of the string
would be a more useful feature than operating on parentheses within a
string's contents.

Re: backward-up-list

[Henrik Enberg]

Richard Stallman <rms@gnu.org> writes:

> If Stefan sees no basic flaw in this, then would one of you like to
> try modifying some of the functions in lisp.el to test this criterion?
> I guess backward-up-list could move backward out of the string
> constant and treat that as one level of list.  Same-level motion
> commands could move to the beginning or end of the string and count
> that as having moved over one sexp.

Yes, I'll take a look at this.  Might take a few days before I find the
time though.

-- 
Booting... /vmemacs.el

Re: backward-up-list

[Stefan Monnier]

>     Of course if backward-up-list can work all within the string
>     (in which it currently already DTRT), it should still DTRT.
> 
> I don't think so.  I think that reliably moving out of the string
> would be a more useful feature than operating on parentheses within a
> string's contents.

I very often use sexp-operations like backward-up-list inside strings
(and even across strings, although it's only by luck that it works ;-).
It's very handy when jumping around regexp groups, for example.

Maybe this usage pattern is unusual, I don't know, but I do know that
I would miss it enough to write a little function to recover the "old"
behavior rather than get used to the new behavior.


	Stefan

Re: backward-up-list

[stl]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> >     Of course if backward-up-list can work all within the string
> >     (in which it currently already DTRT), it should still DTRT.
> > 
> > I don't think so.  I think that reliably moving out of the string
> > would be a more useful feature than operating on parentheses within a
> > string's contents.
> 
> I very often use sexp-operations like backward-up-list inside strings
> (and even across strings, although it's only by luck that it works ;-).
> It's very handy when jumping around regexp groups, for example.

I thought backward-up-list does not work inside a string? Actually thats why
i came up with the first post...

> Maybe this usage pattern is unusual, I don't know, but I do know that
> I would miss it enough to write a little function to recover the "old"
> behavior rather than get used to the new behavior.

Maybe a variable could be used to switch between the two possibilities?
And a toogle function so that one could bind it to a key if need.


Stephan

Re: backward-up-list

[Richard Stallman]

    I very often use sexp-operations like backward-up-list inside strings
    (and even across strings, although it's only by luck that it works ;-).
    It's very handy when jumping around regexp groups, for example.

    Maybe this usage pattern is unusual, I don't know, but I do know that
    I would miss it enough to write a little function to recover the "old"
    behavior rather than get used to the new behavior.

It should not be hard to preserve a way to do what you want.