bug#35496: 27.0.50; smie-blink-matching-open blinks token before point after RET

[Dmitry Gutov]

On 08.05.2019 20:42, Stefan Monnier wrote:

> > But we don't end up blinking to `def` after RET, we blink to `do`.
>
> That's not what I see when I try your recipe: it blinks to the "d" of
> "def", as it should, for me (both with Emacs'` master` and with
> Debian's Emacs-26.1).

You are right. Sorry about that.

I guess the main problem, both the cause of my misunderstanding and the 
user aggravation, is that smie-blink-matching-open calls 
blink-matching-open on a changed position. As a result the sit-for call 
is issued on the position before the newline instead of after.

Which created both the appearance of sluggishness from the original 
report, and my mistake on which token is highlighted (because the moved 
cursor is much easier to notice than the subtle paren highlighting, at 
least on the theme I'm using).

I've tried to move all checks smie-blink-matching-open into a 
save-excursion and call blink-matching-open from the orignal position, 
but that doesn't work alone, unfortunately, because newline is a 
separate token. Hence the change in blink-matching-open as well. WDYT?

Patch attached.

> > SMIE fills it automatically based on the current set of tokens.
>
> Indeed, but you can tweak it by hand afterwards.
>
> > If I add it myself, yeah, the behavior is better in this case.
>
> I've been wondering for a while now if it's not just "in this case" but
> in general.

I don't know. The highlighting itself is sufficiently unobtrusive here, 
so it could work either way. If the patch I'm proposing seems like 
unwanted complexity, we can avoid it also this way, and even simplify 
more code.

> > But I kinda buy your reasoning about not having it there (even though
> > it's not a panacea: the user can type whatever token, not only ones in
> > the smie-closer-alist.
>
> I agree that only considering smie-closer-alist is probably not a great
> choice.  It seemed obvious when I wrote it, but I don't know why, and
> I can't justify it now.
>
> [ Maybe it's because I was working on octave-mode around that time and
>    didn't want to blink on "end" when the user likes to write the
>    full-form "endfunction"?  But even that doesn't sound like
>    a good justification.  ]

I'm guessing that with Elixir's syntax, while the user is typing the 
last two chars in

  def sum, do:

the 'd' in 'def' would blink twice. Which is maybe not ideal either.

> > Overall, I feel that the smie-blink-matching-inners might be too much as
> > default anyway.  So it's not a big deal if elixir-mode has to disable it.
>
> I don't think it's specific to elixir-mode but is rather
> a user-preference.  Maybe it should default to nil, but I haven't
> found a mode where smie-blink-matching-inners should be disabled
> *because of the mode* rather than because that's what the user prefers.

No argument here. Just saying it's an okay workaround as well.

smie-blink-matching-do.diff
Description: Text Data