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

[Stefan Monnier]

>>> 1. Disable show-paren-mode if it's enabled.
>>> 2. Evalute the attached .el file (which defined a major mode).
>>> 3. Create a new bufferand type M-x foo-mode.
>>> 4. Type 'def foo do' (without quotes) and press RET.
>>> 5. Cursor will hang around on the first line even after the newline
>>> is inserted.
>>
>> It's not a bug, it's a feature: we can't highlight the matching `def`
>> when you hit the `o`  because we don't know yet whether you actually
>> intended to type `do` or a longer identifier, so we postpone the
>> blinking to the next char.
>
> 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).

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

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

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


        Stefan