Jinx can cause lockups together with images or emojiis

[Thaodan]

Hello,

Over the last few weeks I noticed that Jinx can cause lookups in a buffer that contains image or emojii is close to the suggestion popup of e.g. company-capf.

For me this issue is usually triggered inside Circe but it might also happen others such as Erc.

I tried to isolate the issue over the last few weeks and could narrow it down. First I thought the word suggestions coming up from Jinx in Circe cause it since I did not got those before but then I learned that Jinx doesn't provide any capf competition.

When the bug is happening the only way to unstuck Emacs is to send (twice) SIGUSR2 to it so it quits.
I have two backtraces when this happened, one
for images and the other when there's a buffer with emojis.

Images:

* help-command-error-confusable-suggestions((quit) "" nil)
  recursive-edit()
  debug(error (quit))
  jinx--find-visible-pending(2921 4654 t)
  jinx--check-pending(2921 4654)
  jinx--timer-handler()
  apply(jinx--timer-handler nil)
  timer-event-handler([t 0 0 200000 nil nil nil idle 0 nil])

Emojiis:

* help-command-error-confusable-suggestions((quit) "" nil)
  recursive-edit()
  debug(lambda)
* #f(compiled-function () #<bytecode 0x10301f637102a72>)()
  emojify-display-emojis-in-region(8633148 8634688)
  emojify-redisplay-emojis-in-region(8633148 8634648)
  #f(compiled-function (fun) #<bytecode 0x1a5ec9801fac953f>)(emojify-redisplay-emojis-in-region)
  jit-lock--run-functions(8633148 8634648)
  jit-lock-fontify-now(8633148 8634648)
  jit-lock-function(8633148)
  redisplay_internal\ \(C\ function\)()

In my case emojify-display-style is unicode which might confuse Jinx.

[Thaodan]

I hope I explained the issue correctly, in case something is missing please ask.

[minad]

Hi Björn! Please provide a precise recipe starting from emacs -Q which I can try to reproduce the issue (ideally only Jinx, without Circe, Emojify or Company). Otherwise I have no possibility to observe this problem myself and debug it.

[Thaodan]

Sure I can try tomorrow. Is this a bug or discussion now?

[minad]

Alternatively you could try to save the (buffer-string) of the buffer where the issue occurred. Then I could recreate the buffer from that and check with Jinx.

[minad]

Sure I can try tomorrow. Is this a bug or discussion now?

Let's wait for your recipe, then I can answer that question. ;)

[minad]

To be clear - if it is a bug in Jinx, it will be fixed. I just added many Emojis to an Emacs buffer without any negative effects on Emacs 29.2. But these were the native Emacs Unicode Emojis, so maybe this makes a difference. Which Emacs version do you use?

[Thaodan]

Daniel Mendler ***@***.***> writes:

To be clear - if it is a bug in Jinx, it will be fixed. I just added many Emojis to an Emacs buffer without any negative effects on Emacs 29.2.

No problem, I was merely confused about the approach to use discussions for unverified issue's.

But these were the native Emacs Unicode Emojis, so maybe this makes a difference. Which Emacs version do you use?

Idk I'll see tomorrow. One thing that's interesting about the problem that it doesn't happen before there's a word/nickname suggestion in Circe. I'm using Emacs 30.50.x but I don't think Emacs 30 or 29 should make a difference in this case Somehow my problem looks similar than the issue someone else reported especially the message containing the backtrace below: #156 (reply in thread)

[minad]

I'm using Emacs 30.50.x but I don't think Emacs 30 or 29 should make a
difference in this case

It can make a difference. Please check both 29 and 30 if possible.

I'm using Emacs 30.50.x but I don't think Emacs 30 or 29 should make a
difference in this case

The problem in the other thread is different, since there Jinx takes a long time checking a very large buffer region due to folding (this is not unexpected, and we discuss potential optimizations in the other thread). In contrast, in your report, the region is pretty small and it seems more related to some specific buffer content (emojis, images, ...).

[minad]

Could you please try 884be31 if this fixes the problem? But this seems like an Emacs bug to me since next-single-char-property-change should always return a value larger than the start position. See also this comment: #156 (comment)

[Thaodan]

Sure, thanks for looking into it.

[Thaodan]

Hey,

I use Jinx with that change for a few weeks now and it seems to fix the issue for me.

[minad]

@Thaodan Thanks. Great for hearing back. Just to be sure - you mean commit 884be31? Now the question remains why this commit fixes the issue. I wonder why the change is necessary. I am kind of confused about the loop which hangs. It looks to me like a bug in the property search function, or doesn't it? What do you think?

[Thaodan]

Yes exactly that commit.

I'm not sure exactly to be honest since the interaction with other packages makes the issue quite ambiguous.

There's emojifii going over the buffer trying to display emojis, Jinx trying to check for spelling errors in the buffer and company spawning a popup over the text based on the results of company-dabbrev.

However the docs say next-single-char-property-change it should never same value as in
POSITION.
So the bugs does clearly appear in that function. I think a workaround is easier to apply now in
case it could also appear on earlier Emacs releases and before there's a fix.