From: Stephen Leake <stephen_leake@member.fsf.org>
To: emacs-devel@gnu.org
Subject: Re: smie-next-sexp vs associative operators
Date: Wed, 24 Oct 2012 19:45:37 -0400 [thread overview]
Message-ID: <851ugna0ym.fsf@member.fsf.org> (raw)
In-Reply-To: <jwvvce0gebb.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 24 Oct 2012 10:24:42 -0400")
Stefan Monnier <monnier@iro.umontreal.ca> 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
next prev parent reply other threads:[~2012-10-24 23:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-14 9:16 smie-next-sexp vs associative operators Stephen Leake
2012-10-14 15:54 ` Stefan Monnier
2012-10-14 18:44 ` Stephen Leake
2012-10-14 21:48 ` Stephen Leake
2012-10-15 1:47 ` Stefan Monnier
2012-10-15 12:09 ` Stephen Leake
2012-10-20 9:15 ` Stephen Leake
2012-10-21 14:58 ` Stephen Leake
2012-10-23 17:37 ` Stefan Monnier
2012-10-23 22:43 ` Stephen Leake
2012-10-24 14:24 ` Stefan Monnier
2012-10-24 23:45 ` Stephen Leake [this message]
2012-10-25 3:01 ` Stefan Monnier
2012-10-25 19:17 ` Stephen Leake
2012-10-25 21:01 ` Stefan Monnier
2012-10-23 18:07 ` Stefan Monnier
2012-10-23 23:14 ` Stephen Leake
2012-10-24 14:44 ` Stefan Monnier
2012-10-25 0:22 ` Stephen Leake
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=851ugna0ym.fsf@member.fsf.org \
--to=stephen_leake@member.fsf.org \
--cc=emacs-devel@gnu.org \
/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.