Closed bhrgunatha closed 2 years ago
Wow! That is... very strange and surprising.
I can reproduce this, even with Emacs 25.2.
I tried setting racket-pretty-print
to nil
instead of t
, but it still happens.
An even more minimal example seems to be:
#lang racket/base
"[{\"type\":\"NumericLiteral\",\"value\":1},{\"type\":\"NumericLiteral\",\"value\":1},{\"type\":\"NumericLiteral\",\"value\":1}]"
Ah. In the racket-repl-mode
buffer, if I M-x font-lock-mode
, then it displays instantly.
Same for you?
It seems to be related to font-locking ("syntax highlighting", in non-Emacs-ese :smile:) this as a Racket value.
racket-mode
(edit) buffers and racket-repl-mode
share a lot of font-lock code. I can't seem to produce a similar problem in a racket-mode
buffer. This might be an interaction of font-lock code that works fine in such buffers, with additional font-locking that is being done in the REPL. I'll take a deeper look...
This seems related to a compilation-mode regexp we set, which tries to match file:line:col in error messages. It seems to be attempting to match this, taking way too long to fail.
Strengthening the pattern to require whitespace at the start would fail faster, but I'm not sure if there was some good reason I didn't use that in the pattern before. So I want to ponder this... but not too long -- this is such a nasty behavior, I'm inclined to merge something faster, even if I need to revisit this and re-fix it differently.
I confirm turning off font-lock-mode results in immediate response. Applying 0e72bed fixes the problem for me. Thanks.
@bhrgunatha Thanks for trying that and confirming. I'm about to merge a slightly different change, which should still work for you. (The more I looked at the regexp, the more I thought it needed to be improved in a few more ways. Then I felt like it was a good opportunity to add some unit tests around this.)
racket-bug-report output
M-x racket-run
Repl displays
then a delay of about 8-10 seconds followed by the rest of the ouput
The following
M-x racket-run
This time Repl displays
then emacs becomes total unresponsive for about 2 or 3 minutes - I'm using a server which hits 25% (on 1 on 4 processors), but not the background racket process, just the emacs server - followed by:
Both of these execute instantaneously in DrRacket, so I feel it's probably not the json library.
Edit: I discoverd this using emacs 29 with native compilation, but to report the bug switched to the official Arch linux emacs 28.1 package - compiled without native compilation.