Re: SMIE implementation for the C-like languages

[Stefan Monnier]

>>> if true {
>>>    |bar
>>> }
[...]
> I'm a bit suspicious about :list-intro 'if', :elem 'args' and that :elem
> 'basic' was requested 2 times, especially if you compare against second
> example I sent yesterday (which has a proper indentation).

Without stepping through the rules-function to see where is what and
comparing to the precise grammar you used, I can't tell you in detail if
that's really necessary or not, but normally the above case will need to
compute the virtual indentation of the "{" and this "{...}" probably
looks like a sexp to SMIE, so SMIE sees the above as "KEYWORD(if) SEXP1
SEXP2", so the "SEXP1 SEXP1" may be a function call (SEXP1 being the
function and SEXP2 the argument).

>> That's because it tries to match "}" with an opening "if" (since your
>> grammar states ("if" exp "{" insts "}") which implies that "{" is an
>> infix terminal).
> Yes that's true, but braces are also a part of the syntax table.

That's right, so there are two conflicting "definitions" of what { and } do.
I'm not surprised that SMIE doesn't deal well with such situations,
because I'm myself not really sure how it should be handled.

> Since smie allow any sequence of sexp anywhere, I think this code
> block should be handled.

But the smie-grammar refines the definition of "sexp" provided by the
syntax-table, so it's not clear any more whether "{...}" is really
a sexp or is only the second half of "if ... { ... }".

> I'm not sure what is the best way to do that but maybe something like
> a fallback logic to the syntax tables for such cases?

I understand what you mean, but I don't know how to translate that into
code, because once you look at it from the code's point of view, the
requirements are often conflicting.

>>> But it doesn't change behavior of the blinking: for the same if
>>> construction blinking happens for the "if" token.  Is there a different
>>> way of altering this behavior?
>> My guess would be that the default blinking code uses forward-sexp which
>> goes through forward-sexp-function which SMIE sets up as well.  Try set
>> this var back to nil in swift-mode buffers, see if that helps.
> I tried to reset forward-sexp-function and it works when I'm not
> tokenizing braces. When braces handled in lexer, I'm getting "Mismatched
> parenthesis" error similar to one of the previous examples.

I suggest you report this as a bug as well, providing enough details to
reproduce it.  I don't know if it's indeed a bug or not, but we need to
investigate in more details.


        Stefan