Re: smie-next-sexp vs associative operators

[Stephen Leake]

Stefan Monnier <address@hidden> writes:

>>>> 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).

I don't understand this.

As I pointed out back near the start of this thread, when modula-2-mode
is indenting the token after "then", smie-indent-after-keyword calls
smie-indent-virtual to compute the indentation for "then"; that calls
smie-indent-keyword. If m2-smie-rules doesn't handle it,
smie-indent-keyword calls calls (smie-backward-sexp token), with `token'
= "then". This parses all the way back to "if".

So yes, smie-backward-sexp is called in indentation functions. And it is
the typical case; there are very few overrides in m2-smie-rules.

But perhaps modula-2 is not a good example, and I should look at the
others.

> There's something wrong if you need to write that for indentation of
> the if..end construct.

You keep saying this, and I keep pointing out that the smie engine does
it all the time.

>> 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'.

Yes. But thought there might be some legal language construct that
required it as well. For example, indenting math expressions, since the
comment in smie--associative-p talks about "+".

> 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.

That's a reasonable heuristic.

It's not what modula-2 mode does.

Which language does that? I'd like to study the code.

>>> 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.

I don't understand. The language implementor can set it to nil by
default, to get the above properties. Then during indentation, it can be
let-bound to t.

I guess your point is that if the t functionality is provided in a
different function, that function can be called from the indentation
rules, while the nil function can be called from the motion code.

But that duplicates a _lot_ of code, for one very small change. A
let-bound option is a much simpler solution.

> So if you need it for particular indentation rules, that's OK, but it
> should not affect general movement behavior.

Right; a let-bound option satisfies that.

>> Since the right value for smie-skip-associative is tied to the language,
>
> I still don't believe it to be the case.

It is for Ada.

--
-- Stephe