Fork me on GitHub

@borkdude what happened to this highlighting thing? code link is dead


I ended up using a .js highlighter since this simplified building the blog a little bit, but I can dig up the code if you want to look at it, from the git history


so you wouldn't recommend doing the server side thing? or any other issues?


I can dig out the code myself, just thought I ask why its gone 😛


This is the server side solution: If you're on the JVM you can use clj-kondo directly rather than the pod. Or leave it out: it only improves the situation for coloring locals that have the same name as clojure vars, for example.


> so you wouldn't recommend doing the server side thing? It depends: this code is for generating static assets and in the end I went with prism.js which I found not perfect, but good enough, and relatively small


I'm parsing some code in CLJ and just want basic highlighting when dumping it out into html


feel free to re-use that code, I think it makes sense


thanks, I'll think I go with something like this


I want to make stuff clickable so it takes you to the source location


so can't just use a pure JS highlighter anyways


I think this looks like a good base


I'll tinker and let you know


I also have a documentation solution which analyzes vars (statically) and adds source links: Also based on clj-kondo


but I guess in shadow-cljs you know the source locations at runtime


its for a thing I'm building, similar to clerk in some ways. don't just want to display the code, want to make it clickable so it takes you to the source

Braden Shepherdson18:02:11

is there any way under shadow-cljs to set the Closure options object? I want to set CompilerOptions.setCrossChunkMethodMotion(false) because I'm having issues with Malli caused by


:compiler-options {:cross-chunk-method-motion false}


which version do you use though? this should be fixed?

Braden Shepherdson18:02:27

version of which? that bug is still open against CLJS.




I hacked reify to emit different code, which should prevent this


should be fixed since 2.20.19

Braden Shepherdson18:02:03

ah, it was 2.19.6. I didn't realize we were trailing that far. let me try that!

Braden Shepherdson18:02:20

works great! thanks for the pointer, I never considered that possibility.

👍 1

Is there a way to use build hooks to set Closure defines for the application to pick up later? I’m looking for a way to automatically inject some information about the project’s repository into the application so that I can display a version number, etc.


I had seen that, but I didn’t want to have to worry about passing it on the command line. Ended up with this:

(defn- scrape-command
  (-> (apply shell/sh args)

(defn export-repo-version
  { :configure}
  (let [branch       (scrape-command ["git" "rev-parse" "--abbrev-ref" "HEAD"])
        commit-count (scrape-command ["git" "rev-list" "HEAD" "--count"])
        defines      {' branch
                      ' commit-count}]
    (println (str "export-repo-version - branch is '" branch "', commit-count is " commit-count "."))
    (update-in build-state [:compiler-options :closure-defines] #(merge % defines))))


Thank you for shadow-cljs, by the way!


Hello @thheller I'm not very sure if this is shadow-cljs related... I found a strange compilation output, for the following cljs code (note that the parameter arguments in the protocol definition are all _):

(defprotocol IState
  "Additional state/introspection abstraction."
  (-extract [_] [_ _] [_ _ _] "Extract the current value."))
The generated code looks like this:
// [...]

(promesa.protocols._extract.cljs$core$IFn$_invoke$arity$2 = (function (_,___$1){
if((((!((___$1 == null)))) && ((!((___$1.promesa$protocols$IState$_extract$arity$2 == null)))))){
return ___$1.promesa$protocols$IState$_extract$arity$2(___$1,___$1);
} else {
return promesa$protocols$IState$_extract$dyn_43250(___$1,___$1);

// [...]
You can observe that on arity 2 the argument passing on the following function call are all the same (repeated twice) If I define the protocol with argument names, I mean (-extract [it] [it default] [it default default2] "Extract the current value.") The problem disappears and the compilation results in:
// [...]

(promesa.protocols._extract.cljs$core$IFn$_invoke$arity$2 = (function (it,default$){
if((((!((it == null)))) && ((!((it.promesa$protocols$IState$_extract$arity$2 == null)))))){
return it.promesa$protocols$IState$_extract$arity$2(it,default$);
} else {
return promesa$protocols$IState$_extract$dyn_37688(it,default$);

// [...]
Is this expected behavior and the _ can't be used repeatedly as param placeholder or there is a bug somewhere? Thank you very much.


interesting, but this would be a cljs issue. not something shadow-cljs influences or controls in any way. given that the defprotocol definitions are also sort of documentation I'd have a hard time figuring out what arguments you are supposed to pass? so not great just definining _ in the first place, but should probably file a bug regardless


yeah, that was initial only a single first argument with _ that is ok because it represents this but the other one was just quick prototyping.


I have no permissions on jira, so I guess I need to wrinte on the ask.clojure right?


that is best probably. or ask in #C07UQ678E, best to have a quick repo