[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: smie-next-sexp vs associative operators

From: Stefan Monnier
Subject: Re: smie-next-sexp vs associative operators
Date: Tue, 23 Oct 2012 14:07:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

> This is the prefered indentation. I'm using it as an example of a case
> when calling smie-backward-sexp is necessary, when computing the
> indentation of F.

Yes, smie-backward-sexp is often needed, but very rarely directly in
indentation rules.

> That's what modula-2-mode does as well; smie-indent-after-keyword calls
> smie-indent-virtual to compute the indentation for "then"; that calls
> smie-indent-keyword, which calls (smie-backward-sexp token), with
> `token' = "then". This parses all the way back to "if".

That's actually a bug: the THEN should be indented relative to its
corresponding ELSIF (if any) rather than to the top IF.

>> More specifically, with point right after an "elsif", I'd expect C-M-b
>> to stop right after the previous "elsif".
> How is that useful for indentation?

It's useful because it lets the indentation work by looking at a smaller
part of the buffer.  This is good for performance, and 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

To my mind, if...elsif...end, is very much like Elisp's `cond', so every
"exp THEN stmt" is a "branch", and those branches are connected at
a higher level via "IF branch ELSIF branch ... ELSIF branch ... END".

> What about C-M-b after "else"; should that stop on the preceding "then"?

No, since "then" is in a lower-level of the parse tree.

> or "elsif"?

That would make sense, yes.

>> (exp ("if" expthenexp "end")
>> ("if" expthenexp "else" exp "end")
>> ("if" expthenexp "elsif" expthenexp "end")
>> ("if" expthenexp "elsif" expthenexp "end")
>> (expthenexp (exp "then" exp))
> I tried that (see the attached example_grammars.el, grammar-3). It does
> change the levels assigned by the grammar compiler. But "then" does not
> have equal left and right levels, and the behavior of smie-backward-sexp
> is no more useful, as far as I can tell.

I don't know what would be "useful" to you and/or why the changes
aren't "useful".

> I've verified that the patch shown below allows me to make
> smie-backward-sexp behave the same for the Ada "select/or" and
> "if/elsif" statements. 

Can you tell me in terms of C-M-f or C-M-b in which circumstance they
don't behave identically (and show me the corresponding grammar rules
you're using)?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]