Emacs got stuck sometimes got stuck after installing jinx

[StillerHarpo]

My Emacs sometimes got stuck after I installed jinx. This happens in a Haskell file (I don't know if that is relevant)

Relevant lines in my config

• jinx configuration
• haskell-mode configuration

Stacktrace (sending kill -SIGUSR2)

Debugger entered--entering a function:
* #f(compiled-function () #<bytecode -0x141ff7d6d6162246>)()
  syntax-propertize(31161)
  internal--syntax-propertize(29161)
  jinx--check-region(29106 29124 nil)
  jinx--check-pending(27474 29124)
  jinx--timer-handler()
  apply(jinx--timer-handler nil)
  timer-event-handler([t 0 0 200000 nil nil nil idle 0 nil])

Emacs version:

emacs --version
GNU Emacs 30.0.50
Copyright (C) 2024 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

[minad]

Hi @StillerHarpo, the hanging occurs in an function of the syntax properties handling. I don't see problems with haskell-mode+jinx-mode on Emacs 29.3. Did you observe such issues before on Emacs 29? This could also be an upstream problem, but I am not aware of changes to the syntax machinery in Emacs 30. There have been changes to the regexp engine though. In that case, some bisection of the Emacs source would be needed.

[StillerHarpo]

Hi @minad . I only used jinx in Emacs 30. I will try to bisect the problem over the weekend.

[minad]

Okay, this would be great. If this is an Emacs 30 problem it would be nice to know and report it upstream such that it can be fixed before the next Emacs release.

[StillerHarpo]

I also see this problem on emacs 28.2. This happens when company tries to autocomplete with company--etags and there is a string literal on screen in a file with some specific properties (which i couldn't find out yet) . I seen it only in one Haskell file (which is unfortunately proprietary).

My minimal emacs config to reproduce this:

(require 'use-package)

(use-package company
  :custom
  (company-backends '(company-etags))
  :config
  (global-company-mode))

(use-package jinx
  :custom
  (jinx-languages "en_US")
  :init
  (global-jinx-mode 1))

[minad]

Thanks for reporting back. This is unfortunately a setup which I cannot easily test myself, despite using Haskell from time to time. For now I suggest to disable either Company or Jinx in Haskell files.

[yantar92]

Not directly related to haskell-mode, but I am also getting Emacs being stuck after I tried jinx. Specifically, when I have frames left around with huge Org documents where Mbs of text are folded away. "Emacs stuck" means that I have to wait a long time before I can create a new Emacs frame via emacsclient. I can sometimes force "unstuck" by switching to the existing frame and pressing some keys. I suspect that the algorithm searching for invisible parts of the buffer is too inefficient.

[yantar92]

It is as efficient as possible. Do you have a better suggestion?

Maybe jinx--schedule can accept arguments beg..end and pass them to jinx--timer-handler, so that it does not unconditionally try to check the whole window-start..window-end?

[yantar92]

Also, jinx--timer-handler may avoid re-checking already checked buffers if they are displayed in multiple frames. Escpecially when the displayed portions of buffers are the same.

[minad]

Maybe jinx--schedule can accept arguments beg..end and pass them to jinx--timer-handler, so that it does not unconditionally try to check the whole window-start..window-end?

No, this won't work, since we will get many regions and this would mean that we have to start multiple times, which is better avoided.

Also, jinx--timer-handler may avoid re-checking already checked buffers if they are displayed in multiple frames. Escpecially when the displayed portions of buffers are the same.

Iirc Jinx checks the window region in all frames. But if a region has already been checked there won't be any jinx--pending properties left. This leaves us again with the inefficiency of locating these properties in the first place. So we are back to a separate data structure again (my suggestion above).

[walseb]

@minad

I believe @walseb also uses Jinx with large Org files. Maybe he has discovered issues too? In any case, patches improving performance are welcome.

Thanks for pinging me! Yes, I have had a few lockups that might be related to Jinx. I have no clue what caused them, but I do usually have massive org files with many indirect buffer clones open in the background when they occur. I had this backtrace saved in my todo list in case it helps. It seems like Jinx wants to scan large parts of some buffer.

Debugger entered--entering a function:
* help-command-error-confusable-suggestions((quit) "" nil)
  recursive-edit()
  debug(lambda)
* substitute-command-keys("Quit")
  jinx--find-visible-pending(6549815 23016962 t)
  jinx--check-pending(6549815 23016962)
  jinx--timer-handler()
  apply(jinx--timer-handler nil)
  timer-event-handler([t 0 0 50000 nil nil nil idle 0 nil])

[minad]

@walseb Yep, this looks similar to @yantar92's problem. I believe the solution is to store the pending regions not as text properties, but as a separate data structure. Then we avoid expensive scans over large regions.

[rdiaz02]

I am facing a similar problem. One instance that just happened to me involved a buffer with R code (in this particular case, it could also have involved company, as in #163, as the argument of a function had just been completed via company): I was writing an R expression and Emacs locked, and I sent (once) SIGUSR2 to it.

The backtrace shows

Debugger entered--Lisp error: (quit)
  jinx--find-visible-pending(2700 4477 t)
  jinx--check-pending(2700 4477)
  jinx--timer-handler()
  apply(jinx--timer-handler nil)
  timer-event-handler([t 0 0 200000 nil nil nil idle 0 nil])

Unfortunately, I cannot find a way to reproduce these lock ups at will.

[minad]

Which Emacs version do you use? 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.

[rdiaz02]

Which Emacs version do you use?

29.3.50

Could you please try 884be31 if this fixes the problem?

Using it now. Will report if I see the problem (note, though, that this is rather unpredictable)

[benthamite]

Just to report that I am also facing this problem. Emacs regularly freezes and when I run pkill -SIGUSR2 Emacs in the terminal, I get the following backtrace:

Debugger entered--entering a function:
jinx--find-visible-pending(3538 9784 nil)
jinx--check-pending(3053 9784)
jinx--timer-handler()
apply(jinx--timer-handler nil)
timer-event-handler([t 0 0 200000 nil nil nil idle 0 nil])

It doesn’t seems to happen in any particular major-mode, though I’ll keep an eye on it and report back if I find any pattern.

Jinx: 77cac7f
Emacs: GNU Emacs 29.3 (build 2, aarch64-apple-darwin23.2.0, NS appkit-2487.30 Version 14.2.1 (Build 23C71)) of 2024-04-26

[minad]

See this comment: #156 (reply in thread)

Maybe the commit mentioned there helps - but either I am confused about progress of the loop or it is a bug in Emacs.

[bclark-videra]

I'm seeing this pretty reliably when I'm adding contents at the end of a buffer and get a code suggestion from https://github.com/copilot-emacs/copilot.el.

I'll try 884be31 and report back.

[minad]

Another option could be to return end from jinx--find-visible-pending if end is larger than point-max. This should fix the issue at a single place.

[bclark-videra]

I'll test and create a PR.

[minad]

Thanks. I made another attempt in 7a7f5f0. This one should work correctly, since it is similar to the older patch, which you've tested first. If you are okay with this one, we can just leave it at that.

[bclark-videra]

7a7f5f0 is working great. Thanks again.

[minad]

Great! Thanks a lot for testing and for helping figuring this out!