Error: "Invalid search bound (wrong side of point)"

[disconsis]

Hey, I've been having a great time with the package. Thanks for your great work!
I've been noticing some jit-lock errors and I narrowed it down to prism.

My setup is GNU Emacs 29.0.60, with Doom emacs, and prism v0.3.2

It's only with one emacs lisp file, and it's some weird combination of length of the file (like 600 lines) and a comment line. Bisecting the file itself hasn't gotten much info, but it seems like it only occurs when there's at least a full window of content and something to do with this starting section of the file:

;;; -*- lexical-binding: t; -*-

;; Some functionality uses this to identify you, e.g. GPG configuration, email
;; clients, file templates and snippets.
(setq user-full-name    "Ketan Kanishka"
      user-mail-address "ketan.kanishka@nyu.edu")

;;; Utility functions
;; Due to name visibility issues, this section needs to be at the top.

;; 12-hour time -> 24-hour time
(defun pm (hour) (mod (+ hour 12) 24))
(defun am (hour) hour)

(defun my/load-doom-theme (&optional theme)
  "Load the currently set `doom-theme'. If THEME is provided, set it to `doom-theme' first."
  (setq doom-theme (or theme doom-theme))
  (load-theme doom-theme t nil))

(defun silently (fn)
  "Run FN without showing any messages in echo area."
  (let ((inhibit-message t))
    (funcall fn)))

and especially this line - "Some functionality uses this to identify you, e.g. GPG configuration, email" seems to be causing issues.

Since this error was thrown by jit-lock-mode, I wasn't able to debug it very effectively.
However, I've narrowed it down to this section:

                                 (when (re-search-forward (rx (or (syntax string-quote)
                                                                  (syntax comment-start)))
                                                          (or (ignore-errors
                                                                (scan-lists (point) 1 1))
                                                              limit)
                                                          t)

Specifically, it seems like re-search-forward, even when its noerror argument is true, raises an error when the current point is less than the bound argument.
After modifying the section to:

                                 when (condition-case err
                                           (let ((regex (rx (or (syntax string-quote)
                                                                (syntax comment-start))))
                                                 (my-limit (or (ignore-errors
                                                                 (scan-lists (point) 1 1))
                                                               limit)))
                                             (message
                                              "calling (re-search-forward :regex %S :limit %S 'noerror) [current-point: %S, limit: %S]"
                                              regex my-limit (point) limit)
                                             (re-search-forward regex my-limit t))
                                         (error
                                          (message "caught error! %S" err)
                                          nil))

I get these logs:

...
calling (re-search-forward :regex "\\s\"\\|\\s<" :limit 1551 ’noerror) [current-point: 1492, limit: 1552]
calling (re-search-forward :regex "\\s\"\\|\\s<" :limit 1551 ’noerror) [current-point: 1550, limit: 1552]
calling (re-search-forward :regex "\\s\"\\|\\s<" :limit 1552 ’noerror) [current-point: 1553, limit: 1552]
caught error! (error "Invalid search bound (wrong side of point)")

So I think wrapping this (and maybe also the other) re-search-forward calls with ignore-errors will be at least a good band-aid fix. I'm not sure about the true cause of this though.

Best
Ketan

[alphapapa]

Hi Ketan,

Thanks for the kind words. I'm glad to hear that it's useful to you. prism makes my coding much more enjoyable as well.

And thanks for reporting this bug. I have noticed it myself since making one of the bug fixes in recent releases. Unfortunately, it didn't seem to happen until after I had made the release containing it. However, other than the "Invalid search bound" showing up in the messages buffer, the only problem I've noticed is that sometimes it causes occur to fail if the whole buffer hasn't been font-locked yet, which is annoying, but relatively minor for me.

Anyway, as you've probably noticed, debugging this function can be tedious, despite my best efforts to write the code in an understandable way, so I haven't dug into it yet. I'm sure the fix will be simple, once it's found; probably just a minor logical mistake in the point's position. And, thankfully, your having found a way to reproduce the problem should help with that.

I can't promise to work on this soon, as I have a lot going on right now, but when I do, this information will undoubtedly help.

Thanks,
Adam

[alphapapa]

By the way, if you happen to want to dig into this any further, a couple of tips:

• The font-lock-studio package provides a way to step through font-lock-keywords and associated functions. (I can't offer much guidance about using it, other than to suggest looking at the docs and the key bindings and experimenting. It's a bit awkward, but once you get the hang of it, it can be helpful.)
• As you probably noticed, debugging a font-lock matcher function that's actively font-locking the buffer is difficult (and can sometimes lead to infinite loops and having to kill Emacs). An alternative is to disable prism-mode, then call the matcher function manually with point at a certain place and a certain limit argument. Then you can step through the matcher function with Edebug and see exactly what it's doing at each step.

[disconsis]

Thanks for the helpful tips.
I'll try my hand at it if I get some time.

Best
Ketan

[shipmints]

On Emacs 29.3, I'm getting tons of jit-lock-function errors in plain elisp-mode editing init.el (hacking this is a story that has no end)... prism-mode also slowing down editing pretty substantially. I will disable it for now as they're hard to reproduce and my elisp debugging skills are non-existent (but I'd love to help if I can). Prism functionality is excellent except for these errors and performance. I might leave it enabled in prism-whitespace-mode for those buffer types ala python and see if I get errors there. Not sure this report helps in any way, but here it is.

Error during redisplay: (jit-lock-function 137583) signaled (error "Invalid search bound (wrong side of point)")
Error during redisplay: (jit-lock-function 137536) signaled (error "Invalid search bound (wrong side of point)")
Error during redisplay: (jit-lock-function 137468) signaled (error "Invalid search bound (wrong side of point)")
Error during redisplay: (jit-lock-function 137427) signaled (error "Invalid search bound (wrong side of point)")
Error during redisplay: (jit-lock-function 137403) signaled (error "Invalid search bound (wrong side of point)")
Error during redisplay: (jit-lock-function 137370) signaled (error "Invalid search bound (wrong side of point)")
Error during redisplay: (jit-lock-function 137300) signaled (error "Invalid search bound (wrong side of point)")

[alphapapa]

@shipmints FWIW, the errors do occur sometimes often, but I've noticed no performance problems as a result, which is why I haven't dug into the problem yet.

Anyway, IIRC the "invalid search bound" error started with v0.3.3, and the fix in that shouldn't affect you I think, so feel free to test with v0.3.2 and see if you still notice a performance problem.

[alphapapa]

@disconsis @shipmints FYI, I've pushed a workaround/fix for this to master. Please let me know if it solves the problem for you. It seems to for me.

[shipmints]

Seems solved via latest ELPA (I checked it's identical to master). Thank you for following up on this.

[alphapapa]

@shipmints I think you mean MELPA, since prism.el isn't on GNU ELPA. :) Thanks.

[shipmints]

Yeah yeah I'll have to write (rx (zero-or-more anything) "ELPA") from now on :)