Re: smie-next-sexp vs associative operators

[Stefan Monnier]

> I just encountered another case where I need smie-skip-associative t:
> declare
>    <declarations>
> begin
>    <statements>
> exception
>    <exception handlers>
> end;
> "exception" is optional.

OK, so it is associative.  Admittedly, it's a not good, since
"declare/begin/exception/exception/exception/end" doesn't make sense, so
it's not really associative, but it's not too terrible.

You can try to make it non-associative with something like

   (exp ("declare" decls "begin" stmts+exceptions "end")
        ...)
   (stmts+exceptions (stmts) (stmts "exception" exc-handlers))

but it still won't behave like `begin' since the whole stmts+exceptions
is now a sub-tree.
   
> With smie-skip-associative nil, (smie-backward-sexp "exception") stops
> with point after "begin".  But (smie-backward-sexp "end") stops with
> point before "declare".

Starting from where?

> That's not consistent, so it complicates my code, meaning more time
> spent testing.

Can you give me some detail about the complication?

> With smie-skip-associative t, (smie-backward-sexp "exception") stops
> with point before "declare", simplifying the code.

But such a smie-skip-associative also suffers from inconvenients
(e.g. it will make you look further back than needed for some
indentation decisions and will prevent your users from jumping from one
elseif to the next with C-M-f).

My intuition tells me there's a better solution to your particular
problem (one where you don't have to skip over such associative
siblings), but if you really want to do that, I'd rather do it with
a new function (ideally written on top of
smie-next/backward/forward-sexp) than with a configuration variable.


        Stefan