bug#10460: 24.0.92; css-mode sexp movement

bug#10460: 24.0.92; css-mode sexp movement

[Leo]

In a css-mode buffer with the following text:


a {
    color: red;
}

@

Leave point right behind @ and hit C-M-b, point moved to the opening
'{'. Is this correct behaviour?

Leo

bug#10460: 24.0.92; css-mode sexp movement

[Deniz Dogan]

Leo skrev 2012-01-09 02:40:
> In a css-mode buffer with the following text:
>
>
> a {
>      color: red;
> }
>
> @
>
> Leave point right behind @ and hit C-M-b, point moved to the opening
> '{'. Is this correct behaviour?
>

Why not?

bug#10460: 24.0.92; css-mode sexp movement

[Leo]

On 2012-01-09 17:45 +0800, Deniz Dogan wrote:
>> a {
>>      color: red;
>> }
>>
>> @
>>
>> Leave point right behind @ and hit C-M-b, point moved to the opening
>> '{'. Is this correct behaviour?
>>
>
> Why not?

I am new to CSS and I cannot answer this question.

But from the syntax table this seems to be consistent with lisp mode.

Leo

bug#10460: 24.0.92; css-mode sexp movement

[Tom Tromey]

Leo> In a css-mode buffer with the following text:
Leo> a {
Leo>     color: red;
Leo> }
Leo>
Leo> @

Leo> Leave point right behind @ and hit C-M-b, point moved to the opening
Leo> '{'. Is this correct behaviour?

When I do this, point moves to the "a".  This seems clearly wrong to me
-- I think point should be left at the "{".

It seems like a bug in SMIE, in that this ends up calling
(smie-backward-sexp 'halfsexp), which does the wrong thing.

Tom

bug#10460: 24.0.92; css-mode sexp movement

[Stefan Monnier]

> When I do this, point moves to the "a".

It skipped a "statement".

> This seems clearly wrong to me
> -- I think point should be left at the "{".

Why?


        Stefan

bug#10460: 24.0.92; css-mode sexp movement

[Tom Tromey]

>> When I do this, point moves to the "a".
Stefan> It skipped a "statement".

>> This seems clearly wrong to me
>> -- I think point should be left at the "{".
Stefan> Why?

I was going just by how I "know" emacs works, based on using various
other modes for years and years.  That is, consistency with C mode, js
mode, tcl mode, etc.

The docs also indicate that this is how Emacs works.
From "(emacs) Expressions":

    Each programming language mode has its own definition of a "balanced
    expression".  Balanced expressions typically include individual symbols,
    numbers, and string constants, as well as pieces of code enclosed in a
    matching pair of delimiters.
[...]
       To move forward over a balanced expression, use ‘C-M-f’
    (‘forward-sexp’).  If the first significant character after point is an
    opening delimiter (e.g., ‘(’, ‘[’ or ‘{’ in C), this command moves past
    the matching closing delimiter.  If the character begins a symbol,
    string, or number, the command moves over that.
[...]
       The command ‘C-M-b’ (‘backward-sexp’) moves backward over a balanced
    expression—like ‘C-M-f’, but in the reverse direction.  If the
    expression is preceded by any prefix characters (single-quote, backquote
    and comma, in Lisp), the command moves back over them as well.


I suppose this supplies a bit of wiggle room, if you leniently interpret
"prefix characters".

That said it just seems weird to me that, when point is on "{", if
forward-sexp followed by backward-sexp moves to a different spot,
especially given the above documentation.

Tom

bug#10460: 24.0.92; css-mode sexp movement

[Stefan Monnier]

> I suppose this supplies a bit of wiggle room, if you leniently interpret
> "prefix characters".

SMIE interprets "balanced expression" as "a subnode in the AST".

It can surprise at the beginning, indeed, but in my experience, it's
a useful generalization for languages with infix syntax.

Of course, for infix languages, "a + b * c" might be a proper AST
subnode (whereas stopping after "a + b" wouldn't if there's a "* c"
afterwards), but so is "a", when using forward-sexp we have to choose at
which level of the AST we want to jump forward.  In the above case SMIE
will choose "a" over "a + b * c" (i.e. it will choose the
smallest/deepest subnode).

But when faced with "+ b * c", there is simply no proper subnode ahead.
Here, SMIE extends yet again the concept of "balanced expression" in
order to be able to do something meaningful: it jumps over the whole "+
b * c" (i.e. over the infix op plus its right argument).  This is very
handy in languages with few parentheses, letting you advance by "large"
logical units, just like you would in Lisp where every top-level
statement is wrapped inside parentheses.


        Stefan

bug#10460: 24.0.92; css-mode sexp movement

[Tom Tromey]

>> I suppose this supplies a bit of wiggle room, if you leniently interpret
>> "prefix characters".

Stefan> SMIE interprets "balanced expression" as "a subnode in the AST".

Stefan> It can surprise at the beginning, indeed, but in my experience, it's
Stefan> a useful generalization for languages with infix syntax.

I disagree of course, but I will try not to belabor the point.

Stefan> Of course, for infix languages, "a + b * c" might be a proper AST
Stefan> subnode (whereas stopping after "a + b" wouldn't if there's a "* c"
Stefan> afterwards), but so is "a", when using forward-sexp we have to choose at
Stefan> which level of the AST we want to jump forward.  In the above case SMIE
Stefan> will choose "a" over "a + b * c" (i.e. it will choose the
Stefan> smallest/deepest subnode).

I noticed this asymmetry and was going to bring it up in this reply.
Now you've foiled my riposte.

What I mean is that, in the example in this bug, if you do
backward-sexp, then forward-sexp just advances over the "a" and not the
braced pair.

However, this asymmetry does seem less regular, and IMO therefore less
useful, than a simpler lexically-based movement scheme.  Also conformity
with other modes is a distinct plus -- I necessarily touch code in many
languages, and it slows me down when one mode or another violates my
expectations.

Stefan> But when faced with "+ b * c", there is simply no proper subnode ahead.
Stefan> Here, SMIE extends yet again the concept of "balanced expression" in
Stefan> order to be able to do something meaningful: it jumps over the whole "+
Stefan> b * c" (i.e. over the infix op plus its right argument).  This is very
Stefan> handy in languages with few parentheses, letting you advance by "large"
Stefan> logical units, just like you would in Lisp where every top-level
Stefan> statement is wrapped inside parentheses.

It's handy to have movement commands that means "symbol or balanced
paren-like things".  I always thought that was *-sexp.

Tom

bug#10460: 24.0.92; css-mode sexp movement

[Stefan Monnier]

> However, this asymmetry does seem less regular, and IMO therefore less
> useful, than a simpler lexically-based movement scheme.

It's actually more powerful.  E.g. when point is on a comma
separating two arguments, C-M-t swaps the two arguments.

> Also conformity with other modes is a distinct plus

It's consistent with Lisp code (because the new behavior only occurs for
situations which don't exist in Lisp).  But it's not consistent with
non-SMIE non-Lisp-like languages, indeed.

> It's handy to have movement commands that means "symbol or balanced
> paren-like things".  I always thought that was *-sexp.

You can still have that if you set forward-sexp-function to nil.


        Stefan

bug#10460: 24.0.92; css-mode sexp movement

[Tom Tromey]

Tom> Also conformity with other modes is a distinct plus

Stefan> It's consistent with Lisp code (because the new behavior only occurs for
Stefan> situations which don't exist in Lisp).

That's cheating!  Any behavior would be compatible with what Lisp does
here, according to the same logic.

Stefan> You can still have that if you set forward-sexp-function to nil.

Yeah.  I'm going to close this bug.

Tom

bug#10460: 24.0.92; css-mode sexp movement

[Stefan Monnier]

Tom> Also conformity with other modes is a distinct plus
Stefan> It's consistent with Lisp code (because the new behavior only occurs for
Stefan> situations which don't exist in Lisp).
> That's cheating!  Any behavior would be compatible with what Lisp does
> here, according to the same logic.

I wouldn't call it cheating.  The behavior of `forward-sexp' was really
only defined for Lisp.  Extending it to infix languages can be done in
various ways.  Before SMIE, it was done in the way that's simpler to
implement, but it makes you lose the ability to jump over any nodes of
the AST which aren't "atomic" nor wrapped in parentheses (in Lisp,
this is no problem since all nodes of the AST are either "atomic" or
wrapped in parentheses).

In SMIE I decided to extend it in a different way, which takes more work
on the implementation side, but offers more functionality.
Of course "more functionality" inevitably means "different", so some
users are bound to be annoyed.

Stefan> You can still have that if you set forward-sexp-function to nil.
> Yeah.  I'm going to close this bug.

Thanks,


        Stefan