From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Arthur Evstifeev <mail@ap4y.me>
Cc: emacs-devel@gnu.org
Subject: Re: SMIE implementation for the C-like languages
Date: Mon, 09 Nov 2015 10:23:23 -0500 [thread overview]
Message-ID: <jwvbnb3rzey.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87mvun7lnx.fsf@ap4y.me> (Arthur Evstifeev's message of "Mon, 09 Nov 2015 19:05:06 +1300")
> Language itself is close to the family of C-like languages
> with some differences to the language constructions. I'm looking for
> some advice about applying smie to the languages that use braces as a
> terminators for the code blocks.
Indeed, SMIE is not great for that currently.
I have an "smc-mode" (i.e. SMIE-based c-mode) here which I wrote as an
exercise to try and see what it takes to get SMIE working acceptably for
the C language syntax. It's not usable (it was really meant as an
experimental prototype/proof-of-concept), but if you're interested to
look at it, I could make it available somewhere.
> 1. As stated in documentation tokens that are defined in syntax table
> don't have to be tokenised in lexer. I tried to go this way, but
> encountered situations where defined grammars are not respected.
Not sure which situations you're referring to.
> It seems that smie only tries to indent closer token with respect to
> the opener, rather than parent token defined by grammar.
By default, yes. Of course, the smie-rule-function is there to tweak
that as/when needed.
> cases, but I encountered issues with paren blinking: in some
> situations blinking fails with "Mismatched parenthesis".
Same as before: if you don't give an example, it's hard to know what
might be the cause.
> During some tests I decided to change lexer rules for braces to return
> begin/end tokens instead of braces. I noticed that smie still tries to
> indent "}" token in some situations, specifically `:close-all . "}"`.
At this point, I'm very confused, because I don't know what your code
does when, nor when you see which behavior.
> So my question is what will be the semantically correct way of
> handling braces for the C-like languages?
Where? In the lexer, the grammar, or the indentation rules?
Note that even if you answer this question, there's no single right
answer: you largely get to decide and pick between different consequences.
> And secondary question is it expected that smie tries to indent tokens
> that are not returned by lexer?
If your tokenizer returns nil (or "") and you're in front of a paren,
then SMIE will take this paren to be the next token, yes.
> 2. As a sort of continuation of the previous problem, we are having
> problem understanding what will be semantically correct way of defining
> `sexp` for the smie based mode. At the moment we see a different
> behavior between non-smie c++ mode (which is close to the Swift)
> and something like ruby-mode. One of the contributers summarised
> differences in this post
> https://github.com/chrisbarrett/swift-mode/pull/117#issuecomment-154753070.
> I personally think grammar based sexp provided by smie are extremely
> useful, but they yield confusing results when it comes to blinking
> parens. For example grammar for "if" from here:
> https://github.com/chrisbarrett/swift-mode/blob/simplify_smie/swift-mode.el#L74-L129
Does Swift allow a "{ ... }" block to appear on its own (rather than
as part of a while/if/...), like in C?
If it does (and you want swift-mode to support those blocks), then
I think your approach to use rules like
("while" exp "{" insts "}")
will be very problematic because SMIE's parser when parsing backward
(which is the more usual direction) won't know whether to stop after
skipping a {...} or whether to keep going on the off-chance that this
{...} is really part of a for/while/if...
[ The specific complaint you should get is that "{" will appear both as
an "opener" and as a "neither" (aka "inner") token. ]
> works well for indentation and movements, but blinking on the close
> ("}") returns "if" token.
Indeed, if these two notions of "sexp" need to be different, then you should
probably disable SMIE's builtin paren-blinking support.
Stefan
next prev parent reply other threads:[~2015-11-09 15:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-09 6:05 SMIE implementation for the C-like languages Arthur Evstifeev
2015-11-09 15:23 ` Stefan Monnier [this message]
2015-11-10 3:25 ` Arthur Evstifeev
2015-11-10 4:12 ` Stefan Monnier
2015-11-11 1:12 ` Arthur Evstifeev
2015-11-11 14:17 ` Stefan Monnier
2015-11-13 2:10 ` Arthur Evstifeev
2015-11-18 23:14 ` Markus Triska
2015-11-19 3:00 ` Stefan Monnier
2015-11-11 15:59 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvbnb3rzey.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=mail@ap4y.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.