[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: smie-next-sexp vs associative operators
From: |
Stephen Leake |
Subject: |
Re: smie-next-sexp vs associative operators |
Date: |
Wed, 24 Oct 2012 19:45:37 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (windows-nt) |
Stefan Monnier <address@hidden> 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
- Re: smie-next-sexp vs associative operators, (continued)
- Re: smie-next-sexp vs associative operators, Stefan Monnier, 2012/10/14
- Re: smie-next-sexp vs associative operators, Stephen Leake, 2012/10/14
- Re: smie-next-sexp vs associative operators, Stephen Leake, 2012/10/14
- Re: smie-next-sexp vs associative operators, Stefan Monnier, 2012/10/14
- Re: smie-next-sexp vs associative operators, Stephen Leake, 2012/10/15
- Re: smie-next-sexp vs associative operators, Stephen Leake, 2012/10/20
- Re: smie-next-sexp vs associative operators, Stephen Leake, 2012/10/21
- Re: smie-next-sexp vs associative operators, Stefan Monnier, 2012/10/23
- Re: smie-next-sexp vs associative operators, Stephen Leake, 2012/10/23
- Re: smie-next-sexp vs associative operators, Stefan Monnier, 2012/10/24
- Re: smie-next-sexp vs associative operators,
Stephen Leake <=
- Re: smie-next-sexp vs associative operators, Stefan Monnier, 2012/10/24
- Re: smie-next-sexp vs associative operators, Stephen Leake, 2012/10/25
- Re: smie-next-sexp vs associative operators, Stefan Monnier, 2012/10/25
- Re: smie-next-sexp vs associative operators, Stefan Monnier, 2012/10/23
- Re: smie-next-sexp vs associative operators, Stephen Leake, 2012/10/23
- Re: smie-next-sexp vs associative operators, Stefan Monnier, 2012/10/24
- Re: smie-next-sexp vs associative operators, Stephen Leake, 2012/10/24