;; based on awk script from - 
(defn colors-demo
  ([]
   (colors-demo 77 "/\\"))
  ([width input-text]
   (doseq [[n c]  (map-indexed vector (take width (cycle input-text)))
           :let [r (int (- 255 (* 255 (/ n width))))
                 b (int (* 255 (/ n width)))
                 g (if (>= b 128)
                     (- 510 (* 2 b))
                     (* 2 b))]]
     (print (format  "\033[48;2;%d;%d;%dm" r g b))
     (print (format  "\033[38;2;%d;%d;%dm" (- 255 r) (- 255 g) (- 255 b)))
     (print (format "%s\033[0m" c)))
   (println)))

Nice find! > (what any modern terminal supports) I recall having to add some magical incantation for truecolor to work in my iTerm. Which is to say, it doesn't seem safe to assume everyone has their terminal ready for an upgrade. However it would indeed sounds like a good addition to https://docs.cider.mx/cider/additional_packages.html#generic-emacs-extensions , for instance

I'm going to give it a couple days of testing in daily usage to see if it messes up anything. Assuming it's suitable, I'll at least submit a docs PR for it. Thanks

Is there an easy way to keep the existing ansi color hook out of the list? If this hook processes the color sequences, ansi-color-apply would be redundant. I can't think of how this would be an issue, but it feels look double escaping/unescaping data.

Sure,

(setq cider-repl-preoutput-hook (remove #'cider-repl--ansi-color-apply cider-repl-preoutput-hook))

Just encountered this issue when Malli was throwing pretty-printed errors. With regular ansi-codes, the output looked like pic, but with xterm-color, and running xterm-color-colorize-buffer it looked as expected. Is there a way to completely replace ansi-color with xterm-color? If not, is there a similar hook I can set to get it working automatically when the *cider-error* buffer is opened?

If you don't get an answer from norman feel free to raise an issue in CIDER (it also can save you time to check if Malli offers an option controlling colors - it's pretty common)

There is indeed, playing around with it now. I guess I should do a PR to Malli when I figure this out, at least to the docs.

I did forget to come back and submit a PR. I'll try and get on that - it's been working great. I don't know if the error-buffer uses the same ansi function, but it if it does, it should handle these 256 color ansi sequences just fine.

I'll look into it rn. However, just a quick sanity check - would it not be more idiomatic to add those options within an alias in deps.edn, and activate said alias via CIDER? (which as a setting for the Clojure CLI aliases)

You are propably right ;-)

Give you agree it's nicer I'll investigate it later today. If you still feel there's a strong use case, feel free to create an issue - otherwise we'd enjoy leading users into simpler patterns

The only use case I can think of is when someone wanted to keep it out of deps.edn to give different developers the option to have different .dir-locals.el files. In my case your suggestion is superior.

Yeah, normally having an alias named e.g. :nio-opens would not bother the rest of the team. Most often than not it's a nice way to document how-tos.

Maybe extend the warning to "use 'cider-clojure-cli-parameters or alias in deps.edn instead'?

The warning is a generic Emacs deprecation mechanism, so likely not

ok. thank you!