Would I be able to get this code as text? Will be useful in stress testing my hacky AnsiEsc fork!

sure!

(doseq [color (keys term/*colors*)
          :let [color-fn (ns-resolve
                           'clojure.term.colors
                           (symbol (name color)))]]
    (println (color-fn color))
    (println (term/bold (color-fn (str "bold " color)))))

and in the ns form, i have (:require [clojure.term.colors :as term])

oh hey, it looks like it does a bunch more stuff too: https://github.com/trhura/clojure-term-colors

i haven't even tried the fancier stuff, like FG vs. BG colors, blinking text (wat?), underlining

I can promise you blink won’t work

😅

i won't be too upset about that, lol

Hmmmm interesting. Although I can’t think of any other vimmy things that work like this :thinking_face: going to replace the config system with a simple vim table soon anyway.

I’ll give this some thought.

Sorry, that was badly worded

It should have been

When setting a conjure config variable, does it write into a config file (which you’ve implicitly confirmed as no)

So, for example, ConjureConfig log.strip-ansi-escape-sequences-line-limit 0

where is that variable set (permenantly)?

That’s just in memory, like doing let g:…

So no, it doesn’t write anywhere I’m afraid

I’m going to change it all to just be let g:conjure_config.foo.bar = … some time soon

And deprecate the command, I want to make it less special if I can.

kk

I really liked the old approach of having a .conjure file

Hmm that only existed because Conjure ran a JVM that needed configuring. Now it's all in nvims process that config should be done in the nvim way, which is g:... variables... I think. I don't know another plugin that uses it's own config file and syntax :thinking_face: if I did anything like this again it wouldn't be edn.

I kinda want to say "here's the value you need to set, do that where you normally do for all plugins"

As soon as it’s released I’m planning on adding backwards compatible support for these things. I think I will have to make some small changes, I don’t think they use the same op names and arguments? If they do it’ll work out of the box.

I came here to say the same hahaha

This is now fixed on develop 🙂

Screenshot of hell hahahhaah

Yeaaah, it's worse than it seems. The problem with my error handling system there is that it doesn't show the stack trace. So I just had to find it through intuition and knowledge of the code, I won't be so lucky next time.

I've got to add my own error handling in a bunch of deferred callbacks otherwise they just get swallowed (presumably by libuv?) I think.