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