Something changed with printing, now syntax highlighting is confused

[harold]

Actual behavior

I often return sequences of maps to have them printed in the repl. Since upgrading to 0.21.0 I am seeing a lot of confused syntax highlighting like this:

Steps to reproduce the problem

Evaluating this form in the repl is enough to do it:

(for [i (range 40)]
     {:a (java.util.UUID/randomUUID)
     :b "String String String String String String String"})

Environment & Version information

CIDER version information

;; CIDER 0.21.0 (New York), nREPL 0.6.0
;; Clojure 1.9.0, Java 1.8.0_171

Lein/Boot version

$ lein --version
Leiningen 2.9.1 on Java 1.8.0_171 Java HotSpot(TM) 64-Bit Server VM

Emacs version

GNU Emacs 26.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-04-12

Operating system

Ubuntu 18.04

PS. I love Cider it's the best part of my day every day. <3

[bbatsov]

I've noticed this as well recently. Probably it's some regression related to the REPL performance work done by @cichli in that release. We'll have to investigate this further.

[bbatsov]

PS. I love Cider it's the best part of my day every day. <3

Thanks for the kind words! 🙇

[harold]

We'll have to investigate this further.

Great. Let me know if there's anything I can do to help.

[dpsutton]

@harold i feel like i've seen this for a while so:

1. thanks for reporting. things don't happen without that
2. do you know which version you were last on that didn't have this bug?

[harold]

On my main machine I have this in package-list-packages:

0.16.0 I used for a long time, and never saw this particular brand of syntax highlighting confusion.

0.20.0 I used for a much shorter time, and don't recall seeing this, but it could be in there.

For a long time (years) I have had this in my config as well: (setq cider-print-fn 'puget), but after reading about the print improvements in 0.21.0 I commented it out. So if puget use could mask this, it may have been around for a long time.

Does that help/make sense?

[dpsutton]

more info is always helpful :)

i'm thinking this has been there for a while and I may have been the one to break it a few years ago. The breaks in font-locking happen when the response is split over several messages:

(<--
  id         "10"
  session    "714f85bb-5674-4149-8a7e-a08d8f4318fd"
  time-stamp "2019-04-23 22:13:51.769192492"
  value      "({:a0 #uuid "5e7120c0-38a9-4087-a4b5-156d92337968",
  :b0 "S..."
)
(<--
  id         "10"
  session    "714f85bb-5674-4149-8a7e-a08d8f4318fd"
  time-stamp "2019-04-23 22:13:51.811907403"
  value      "bb-2cbf37bdf8a5",
  :b9 "String String String String String ..."
)
(<--
  id         "10"
  session    "714f85bb-5674-4149-8a7e-a08d8f4318fd"
  time-stamp "2019-04-23 22:13:51.813519873"
  value      "
  :b18 "String String String String String String String"}
..."
)

so here it begins a new message in the middle of a response with "bb...". And the font locking breaks there:

I remember there's a function that has to do with context and ansi coloring and I'm looking for that now.

It would be nice if you could confirm if puget as pretty printer can suppress this behavior

[harold]

Ok, just tried w/ puget, syntax highlighting gets lost at the exact same spot as in my first screenshot (see the first gray 'g' about halfway through the print).

So puget no effect as far as I can tell.

[Malabarba]

I get the same bug in other types of buffer (like compilation-mode, or inf-ruby) whenever there's a lot of output being produced really fast. I think it's just a matter of emacs font-locking "skipping" portions of the buffer when it can't keep-up with the speed of the output.

[harold]

I get the same bug in other types of buffer

Be that as it may, some recent change has exacerbated the problem for the Cider repl - since upgrading I experience this on basically every print, while before I don't recall ever having seen it.

[bbatsov]

I'm almost certain this was broken by the streamed printing. It's like the font-locking got applied to the individual chunks that were streamed in the REPL independently, instead of to the REPL buffer as a whole. Someone will have to dig a bit deeper into that problem.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!