|
From: | Dmitry Gutov |
Subject: | bug#35496: 27.0.50; smie-blink-matching-open blinks token before point after RET |
Date: | Wed, 8 May 2019 12:51:00 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |