emacs-devel
[Top][All Lists]
Advanced

[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: Wed, 24 Oct 2012 23:01:35 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

> I don't understand this.

Yes, there's a misunderstanding: I meant that the smie-rule function
almost never *directly* calls smie-backward-sexp.  Of course, the
generic part of the smie indentation relies heavily on
smie-backward-sexp.

I insisted on it, because you seem to pay a lot of attention to how
smie-backward-sexp behaves depending on the way it's called, and
unless you call it directly, you don't have much control over how it's
called.

>> 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.

Yes the engine does it, but you didn't write that code, right?

> 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 "+".

No, IIRC a left-associative infix operator gets indented in the same
way, so you don't need the "associative special case" since you could
just give those operators a left-associative parsing rule and you'd get
that "skip to the very beginning for indentation" behavior.

> It's not what modula-2 mode does.

Not for ELSIF, but it does for all other associative operators such as
commas in arg lists.

> 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.

That would bring back some of the benefits, but not those for
indentation and I still haven't seen a concrete case where such
a setting in indentation would be useful (I'm not saying your case isn't
one such example, but I still haven't seen your concrete case).

> But that duplicates a _lot_ of code, for one very small change. A
> let-bound option is a much simpler solution.

I don't think it can be that much code.  I think it can be implemented
on top of smie-backward-sexp along the lines of:

  (let ((first-token (smie-backward-token))
        data)
    (while (progn (setq data (smie-backward-sexp first-token))
                  (and (smie-associative-p data)
                       (same-precedence first-token data)))))

but still I don't think you need it.

>> I still don't believe it to be the case.
> It is for Ada.

I lack the evidence to be convinced.

>> (IF_END (_ELSIF/ELSE_ (_THEN_ exp1 stmt1) (_THEN_ exp2 stmt2) (stmt3))
[...]
> It is completely orthogonal to the issue of special treatment for
> associative operators; none of these will be associative.

Yes, ELSIF and ELSE will be.

> My initial reaction is "if you want to move from one keyword to the
> previous, write motion code that does that, don't mess with the
> grammar".

I'm just telling you what grammars worked well in my experience.
I'm pretty sure the modula-2 grammar would move further in that
direction if I were to actually use m2-mode and start fixing the
misbehaviors I bump into.

> But it means spending time optimizing the grammar so it has these
> properties. As I've said, I've got way to much work to do, so keeping it
> simple is more important at the moment.

Fine.

>> I don't think it's a question of language (I've implemented SMIE support
>> for Pascal, sh, Modula-2, Prolog, SML/OCaml/Coq, and Octave, which
> Are those in Emacs trunk? I've only looked in 24.2 so far, and there
> only modula and octave use SMIE.

Not all: the pascal, sh, modula-2, prolog, and octave, yes, the sml one
is in the `elpa' branch, and the other two are external (the coq one is
in the ProofGeneral package, and the ocaml one is in the Tuareg-mode
package).

> All of those are far smaller than Ada, by refined keyword count if no
> other measure.

Indeed.

> It's also fair to keep things very simple at first, and only optimize
> when it becomes necessary, and add features like single-keyword motion
> when you have the time.

Fair.  Then let's move on to a more concrete discussion: show me
concrete indentation problems you bumped into.  And I'll try to fix it
without changing either of your grammar or smie.el.
[ I guess this will require me using your code.  ]

> With point after the "else" labeled else-1, C-M-b leaves point before
> "if". For else-2, point is left before "accept A3". For or-2, point is
> left before "accept A2".
> or-2, else-2 are the only exceptions; after all the other keywords,
> C-M-b stops with point before "if" or "select".

Right, because "or" is associative whereas your "elsif" isn't (because
you haven't moved "then" to a sub-tree).

> Setting smie-skip-associative t removes those exceptions; C-M-b gives
> the same behavior after all keywords.

But since all of your "or", "elsif", "else", "select", and "if" are
indented in the same column, it doesn't matter which one is used,
does it?


        Stefan



reply via email to

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