alphapapa
Error during redisplay: (jit-lock-function 3001) signaled (error "prism: Infinite loop detected in ‘prism-match’
Observed with revision 169b49afa91e69d35b8756df49ed3ca06f418d35 (v0.3.2) on Emacs 29.3
Prism suddenly gets deactivated when scrolling the buffer down a bit, when the attached file is opened in the buffer. The full error message is:
Error during redisplay: (jit-lock-function 3001) signaled (error "prism: Infinite loop detected in ‘prism-match’ (buffer:#<buffer xfiltertree-html.lisp> point:3267). Please report this bug")
A gzipped copy of the file triggering this issue is available here:
I see this symbol at that position: :|hx-on:click|. Prism was written initially for Emacs Lisp, which doesn't support that syntax. This should be fixable, but I probably won't have time to work on it soon. Thanks for reporting.
I get the exact error, when opening files with multi-line strings while julia-mode is enabled. For example a file like
"""asdf
qwer
"""
sum([1,2])
Is there a way to get a backtrace? I have tried M-x toggle-debug-on-error, but it is not doing anything.
@YueRen I've never tried Prism on Julia code. You might try prism-whitespace-mode, as it works with Python, which is closer to Julia's syntax than Lisp, I think.
It's hard to get backtraces for code that runs in redisplay and font-lock, I think. You can try the font-lock-studio package, or you can just call prism-match directly on the buffer contents you have there, perhaps stepping through it with Edebug.
@alphapapa Many thanks for the tip with prism-whitespace-mode! That was spot on, please consider my issue as resolved.
@YueRen You're welcome. I'm curious, would you mind sharing a screenshot of some Julia code viewed with prism-whitespace-mode?
Sure thing, here you are:
It improves the readability of the code drastically for me.
@YueRen Thank you! I may add that to a showcase gallery sometime in the future. :)
I've encountered the same bug as OP, also on || syntax in lisp. Are there any plans to fix this? I know it's not syntax you use terribly often, but it does happen, and it's a shame to have the whole file come crashing down on you :)
In any case, great package, keep up the good work!
I've encountered the same bug as OP, also on
||syntax in lisp. Are there any plans to fix this? I know it's not syntax you use terribly often, but it does happen, and it's a shame to have the whole file come crashing down on you :)
Sure, I want it to work for any flavor of Lisp.
The first question that comes to mind is, which Emacs major mode is being used, and how does that mode classify the syntax of the | character in such a position? Prism uses syntax tables as much as possible, rather than hard-coding certain characters, so I wonder if the major mode correctly classifies those characters. If not, the fix might lie in the syntax table rather than in Prism.
In any case, great package, keep up the good work!
Thanks, I'm glad it's useful to you.
That's a good question, and I'm happy to help you hunt this down, but I have to confess I'm pretty new to the world of emacs and lisp in general, so I might ask stupid questions in the process.
From what I can tell, the major mode is "Lisp mode", as in the builtin lisp-mode.el. Before I wrote the response above, I spent some (small amount of) time trying to figure out how to display the syntax table that's in play in order to see if I could figure out what was going on, but I didn't get anywhere. But in any case, this being built-in lisp mode, I think it should be fairly easy to reproduce.
@gabrielshanahan Thanks, that will be helpful to me since my time is limited right now.
The syntax table classification should be visible in the describe-char buffer displayed with C-u C-x =. The Elisp manual also has more information about syntax tables (probably more than you'd want to know). Finally, with M-x find-library RET lisp-mode RET, you can find that library's source code, and somewhere in there should be where it defines its syntax table, which may be a helpful reference.
This is what I get from C-u C-x = when I placed point at the leading | (the trailing one seems to be the same)
position: 3179 of 9187 (35%), column: 4
character: | (displayed as |) (codepoint 124, #o174, #x7c)
charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x7C
script: latin
syntax: " 23bn which means: string,
is the second character of a comment-start sequence,
is the first character of a comment-end sequence (comment style b) (nestable)
category: .:Base, a:ASCII, l:Latin, r:Roman
to input: type "C-x 8 RET 7c" or "C-x 8 RET VERTICAL LINE"
buffer code: #x7C
file code: #x7C (encoded by coding system utf-8-unix)
display: by this font (glyph code):
mac-ct:-*-Menlo-regular-normal-normal-*-12-*-*-*-m-0-iso10646-1 (#x5F)
Character code properties: customize what to show
name: VERTICAL LINE
old-name: VERTICAL BAR
general-category: Sm (Symbol, Math)
decomposition: (124) ('|')
There is an overlay here:
From 3175 to 3186
face hl-line
priority -50
window #<window 3 on app.lisp>
There are text properties here:
fontified t
I also found the following in lisp-mode.el (comment mine):
(defvar lisp-data-mode-syntax-table
(let ((table (make-syntax-table))
(i 0))
(while (< i ?0)
(modify-syntax-entry i "_ " table)
(setq i (1+ i)))
(setq i (1+ ?9))
(while (< i ?A)
(modify-syntax-entry i "_ " table)
(setq i (1+ i)))
(setq i (1+ ?Z))
(while (< i ?a)
(modify-syntax-entry i "_ " table)
(setq i (1+ i)))
(setq i (1+ ?z))
(while (< i 128)
(modify-syntax-entry i "_ " table)
(setq i (1+ i)))
(modify-syntax-entry ?\s " " table)
;; Non-break space acts as whitespace.
(modify-syntax-entry ?\xa0 " " table)
(modify-syntax-entry ?\t " " table)
(modify-syntax-entry ?\f " " table)
(modify-syntax-entry ?\n "> " table)
(modify-syntax-entry ?\; "< " table)
(modify-syntax-entry ?` "' " table)
(modify-syntax-entry ?' "' " table)
(modify-syntax-entry ?, "' " table)
(modify-syntax-entry ?@ "_ p" table)
;; Used to be singlequote; changed for flonums.
(modify-syntax-entry ?. "_ " table)
(modify-syntax-entry ?# "' " table)
(modify-syntax-entry ?\" "\" " table)
(modify-syntax-entry ?\\ "\\ " table)
(modify-syntax-entry ?\( "() " table)
(modify-syntax-entry ?\) ")( " table)
(modify-syntax-entry ?\[ "(]" table)
(modify-syntax-entry ?\] ")[" table)
table)
"Parent syntax table used in Lisp modes.")
(defvar lisp-mode-syntax-table
(let ((table (make-syntax-table lisp-data-mode-syntax-table)))
(modify-syntax-entry ?\[ "_ " table)
(modify-syntax-entry ?\] "_ " table)
(modify-syntax-entry ?# "' 14" table)
(modify-syntax-entry ?| "\" 23bn" table) ;; This might be doing something special with "|"
table)
"Syntax table used in `lisp-mode'.")
(rx-define lisp-mode-symbol (+ (| (syntax word)
(syntax symbol)
(: "\\" nonl)))) ;; This might be doing something special with ":"
But this is the builtin emacs lisp mode, not a third-party plugin, so everything should be "standard", insofar as that means anything of course.
I've also noticed that the problem only arises when the || syntax is used with keywords, as in :|test|. Simply |test| causes no issues. Given that, I'm also including the what-cursor-position for :
position: 3178 of 9187 (35%), column: 3
character: : (displayed as :) (codepoint 58, #o72, #x3a)
charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x3A
script: latin
syntax: _ which means: symbol
category: .:Base, >:Not at bol, a:ASCII, l:Latin, r:Roman
to input: type "C-x 8 RET 3a" or "C-x 8 RET COLON"
buffer code: #x3A
file code: #x3A (encoded by coding system utf-8-unix)
display: by this font (glyph code):
mac-ct:-*-Menlo-regular-normal-normal-*-12-*-*-*-m-0-iso10646-1 (#x1D)
Character code properties: customize what to show
name: COLON
general-category: Po (Punctuation, Other)
decomposition: (58) (':')
There is an overlay here:
From 3175 to 3186
face hl-line
priority -50
window #<window 3 on app.lisp>
There are text properties here:
fontified t
Does that help in any way?
Also, Merry Christmas!
Does that help in any way?
Thanks. It might; I'll have to dig into the Elisp manual on the syntax table details when I have time (which might not be very soon).
Also, Merry Christmas!
Thanks, Merry Christmas to you too.