Re: smie-next-sexp vs associative operators

[Stefan Monnier]

>> That's actually a bug: the THEN should be indented relative to its
>> corresponding ELSIF (if any) rather than to the top IF.
> _all_ of the keywords in the if/then/elsif/else/endif, and in every
> other multi-keyword statement in modula-2 and Ada, work this way; they
> _all_ jump to the first keyword in the statement. Except for the ones
> that happen to be associative. You'd have to totally rewrite
> smie-backward-sexp, to fix this "bug".

SMIE likes to have more structure in its parse tree: instead of an IF
construct having a single level

    (IF_THEN_ELSIF_THEN_ELSE_END exp1 stmt1 exp2 stmt2 stmt3)

it likes to have something deeper, maybe even as deep as

    (IF_END (_ELSIF/ELSE_ (_THEN_ exp1 stmt1) (_THEN_ exp2 stmt2) (stmt3))

One of the advantages being that if a THEN is missing or there's an
extra one somewhere, it should still be able to match the END with
its IF.

> Have people complained about modula-2-mode for this?

Modula-2-mode did not have any indentation until I added the SMIE
indentation (that was actually one reason I chose it: there was no risk
of regression) and noone requested it, which makes me think noone used
this mode.  That's consistent with the fact that Modula-2 is pretty
much dead.  So "no complaint" is not a good indicator.

> But all of this just goes to say that the current behavior of
> smie-backward-sexp for _non_-associative operators is wrong in the first
> place; that's a _major_ redesign!

I don't see why.  If you make your parse tree deeper, you'll get the
same "stop at the closest token" behavior.

BTW, this discussion is really useful to make me figure out some of the
guidelines and design rules that we should document in
SMIE's documentation.

> That is pretty much the crux of the matter; we have different visions
> about how indentation engines should work, partly influenced by the
> different languages we are implementing.

I don't think it's a question of language (I've implemented SMIE support
for Pascal, sh, Modula-2, Prolog, SML/OCaml/Coq, and Octave, which
I think covers a fair variety of syntaxes).
I've just learned to use SMIE to its advantage, whereas you're trying to
fight it.

>> Can you tell me in terms of C-M-f or C-M-b in which circumstance they
>> don't behave identically (and show me the corresponding grammar rules
>> you're using)?
> Not directly, no, because C-M-f doesn't call (smie-backward-sexp
> keyword), it calls (smie-backward-sexp 'halfsexp), which gives different
> behavior.

No, C-M-b gives the same behavior, you just have to start from another
position (i.e. from right after the keyword rather than from before it).


        Stefan