Re: smie-next-sexp vs associative operators

[Stefan Monnier]

>>> That's not consistent, so it complicates my code, meaning more time
>>> spent testing.
>> Can you give me some detail about the complication?
> I'd have to add special cases in the code, which means each special case
> needs to be tested, and maintained.

Without the specifics I can't see what you're referring to.

> (goto-char (nth 1 (smie-backward-sexp (smie-default-forward-token)) 

I've almost never needed to write a call to smie-backward-sexp in SMIE
indentation rules (yes, there are a few exceptions, but only for
constructs that SMIE is unable to parse properly, or for indentation
rules that do not follow the parse-tree structure, such as indentation
of monadic-style code in OCaml).
There's something wrong if you need to write that for indentation of the
if..end construct.

>>> 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
> Not _me_, just the CPU. That's ok, that's what CPUs are for! as long as
> it takes less than noticable time (which it does, so far, on my
> admittedly very fast machine). And it gives that gain only for a very
> small set of keywords (two out of 130 for Ada mode); from most of the
> keywords in statements, smie-backward-sexp will parse back to the
> statement start.

Indentation of an ELSIF with your approach takes time proportional to
the whole IF construct, thus leading to O(n^2) complexity when
reindenting the whole IF construct, whereas if you only go back to the
previous ELSIF, the total complexity stays at O(n).

But admittedly, the problem is not really performance.

> Do you have any examples of when smie-skip-associative nil is useful for
> actual indentation issues?

As mentioned:

   It is good for graceful degradation (when we misparse some part of
   the code).  It's also useful when the user doesn't like the
   auto-indentation's choice, since we use the user's choice of where to
   indent the previous `elsif'.

E.g., we have the following code:

     case foo of
          | 1 => toto
          | 2 => titi
     | 3 => tata

Assuming that the indentation rule for "| in case" says to align | with "case"
when hitting TAB on the last line, should we leave the line unchanged or
should align it with the previous line?

SMIE will usually align it with the previous line, on the principle that
the user's choice on previous lines takes precedence over the
indentation rules.  After all, if the user doesn't like it, she can
first reindent the other lines, so there's no loss of functionality.

> The comments imply that's why the special treatment was introduced in
> the first place.

It's also handy to hit M-C-t with point on a | to swap two branches of
the above "case" (admittedly, it won't work for your ELSIFs because
M-C-t currently makes unwarranted assumptions and hence only behaves
that way for infix operators that have "punctuation syntax" in the
syntax table).  Or to hit M-C-SPC to select a branch (or a few
branches, if you repeat it).

>> 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.
> Can you explain a little more about the downside of having this choice
> provided as a configuration option? It's not a _user_ option, just a
> language programmer option. It doesn't significantly complicate smie!

Because it breaks the above desirable properties.  So if you need it for
particular indentation rules, that's OK, but it should not affect
general movement behavior.

> Since the right value for smie-skip-associative is tied to the language,

I still don't believe it to be the case.  I think if you should start
from "smie-skip-associative is not an option", you'll soon see that life
isn't that bad after all.


        Stefan