[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SMIE implementation for the C-like languages
From: |
Stefan Monnier |
Subject: |
Re: SMIE implementation for the C-like languages |
Date: |
Wed, 11 Nov 2015 09:17:19 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
>>> 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
- SMIE implementation for the C-like languages, Arthur Evstifeev, 2015/11/09
- Re: SMIE implementation for the C-like languages, Stefan Monnier, 2015/11/09
- Re: SMIE implementation for the C-like languages, Arthur Evstifeev, 2015/11/09
- Re: SMIE implementation for the C-like languages, Stefan Monnier, 2015/11/09
- Re: SMIE implementation for the C-like languages, Arthur Evstifeev, 2015/11/10
- Re: SMIE implementation for the C-like languages,
Stefan Monnier <=
- Re: SMIE implementation for the C-like languages, Arthur Evstifeev, 2015/11/13
- Re: SMIE implementation for the C-like languages, Markus Triska, 2015/11/18
- Re: SMIE implementation for the C-like languages, Stefan Monnier, 2015/11/18
- Re: SMIE implementation for the C-like languages, Stefan Monnier, 2015/11/11