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

Previous Next

Full log

Message #14 received at 35496 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 35496 <at> debbugs.gnu.org
Subject: Re: bug#35496: 27.0.50; smie-blink-matching-open blinks token before
 point after RET
Date: Wed, 8 May 2019 12:51:00 +0300

On 08.05.2019 4:44, Stefan Monnier wrote:
>> 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`.

There must be an opportunity to check that we don't blink to the 
preceding token.

> smie-blink-matching-triggers defaults to ?\s and ?\n so the "next char"
> where the blinking can happen is SPC or RET.
> 
> Maybe we shouldn't postpone the blinking (i.e. we should add ?o to
> smie-blink-matching-triggers)?

SMIE fills it automatically based on the current set of tokens. If I add 
it myself, yeah, the behavior is better in this case. 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.

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.