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

Previous Next

To reply to this bug, email your comments to 35496 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; smie-blink-matching-open blinks token before point after RET
Date: Mon, 29 Apr 2019 23:57:03 +0300

[Message part 1 (text/plain, inline)]

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.

Key moments: ?o is not in smie-blink-matching-triggers because the
grammar also defines a closer 'dop'. smie-blink-matching-inners is t
(which it is by default).

Here's an old bug report for elixir-mode which, unfortunately, didn't
reach the end of the investigation before the author opted for a
workaround instead: 
https://github.com/elixir-editors/emacs-elixir/issues/363

What would be the better workaround, by the way? I'm thinking of simply 
disabling smie-blink-matching-inners.

In GNU Emacs 27.0.50 (build 52, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2019-04-28 built on zappa
Repository revision: 80822917736edbab77969c4a18dfb8dd20fe3a88
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: Ubuntu 18.04.2 LTS

[smie-blink-matching-inners.el (text/x-emacs-lisp, attachment)]

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

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

Stefan, just making sure you read this.

On 29.04.2019 23:57, Dmitry Gutov 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.
> 
> Key moments: ?o is not in smie-blink-matching-triggers because the
> grammar also defines a closer 'dop'. smie-blink-matching-inners is t
> (which it is by default).
> 
> Here's an old bug report for elixir-mode which, unfortunately, didn't
> reach the end of the investigation before the author opted for a
> workaround instead: 
> https://github.com/elixir-editors/emacs-elixir/issues/363
> 
> What would be the better workaround, by the way? I'm thinking of simply 
> disabling smie-blink-matching-inners.
> 
> In GNU Emacs 27.0.50 (build 52, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
>   of 2019-04-28 built on zappa
> Repository revision: 80822917736edbab77969c4a18dfb8dd20fe3a88
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
> System Description: Ubuntu 18.04.2 LTS

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35496 <at> debbugs.gnu.org
Subject: Re: bug#35496: 27.0.50;
 smie-blink-matching-open blinks token before point after RET
Date: Tue, 07 May 2019 21:44:24 -0400

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

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)?


        Stefan

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.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
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, 08 May 2019 13:42:19 -0400

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

Message #20 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: Mon, 13 May 2019 03:52:04 +0300

[Message part 1 (text/plain, inline)]

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 (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 35496 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#35496: 27.0.50; smie-blink-matching-open blinks token
 before point after RET
Date: Wed, 22 Sep 2021 23:34:05 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

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

I've just skimmed this thread, but there didn't seem to be any followup
here?  Is this still an issue in the current Emacs?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 35496 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#35496: 27.0.50; smie-blink-matching-open blinks token before
 point after RET
Date: Thu, 23 Sep 2021 02:12:01 +0300

On 23.09.2021 00:34, Lars Ingebrigtsen wrote:
> Dmitry Gutov<dgutov <at> yandex.ru>  writes:
> 
>> 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.
> I've just skimmed this thread, but there didn't seem to be any followup
> here?  Is this still an issue in the current Emacs?

Yep. No change here.

Regarding the posted patch, I'm not sure it's doing TRT semantically, so 
I didn't press on it.

Previous Next

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