Fork me on GitHub

@james.amberger I have some useful mappings for Conjure and CoC here May be useful. Take what you like, reject what you don't 🙂

gratitude-thank-you 1

Hey all - I just switched from CoC to nvim-lsp/cmp/treesitter. I’m using the recommended cmp treesitter plugin - - and the syntax highlight is terrible. Not even keys are highlighted for me, which is an absolute no go. Does anyone have any suggestions on configuring lsp/cmp/treesitter with clojure? Or alt tools they’d recommend that work with LSP for highlighting?


Hey, have you enabled syntax highlight for treesitter? it needs to be enabled explicitly


my setup too is lsp/conjure/treesitter


Is this what your highlighting looks like? I have highlight explicitly enabled


right, does your colorscheme supports treesitter maybe?


I'd love to know if there is anything on treesitter that semantic tokens from LSP doesn't have?


i remember getting weird highlights when using a colorscheme that doesnt support treesitter


yeah, maybe vim doesn't play well if you enable both, it s worth to test both I think


I wonder if vim uses semantic-tokens, I've seen some strange highlights even after I want back to clojure.vim from treesitter


In some cases just forcing vim to reload file fixes them, so could just be vim not triggering update


I don't remember nvim-lspconfig mentioning anything about highlight


One benefit for neovim-treesitter over lsp would be that neovim can also use treesitter to indent code while you are writing. (Experimental feature) Lsp can format file or range but it needs to be called separately.


yeah, I think semantic tokens from lsp would be the best as it has static analysis and everything to know what each token is and color it properly


but not sure if neovim supports it yet


lol trying other packages for my theme and everything is in cursive 😭

🤯 3

Neovim doesn't support Semantic tokens yet, there is a WIP PR:

👍 1
thanks 1

So eventaully got into the weeds and getting closer to a theme. However, my warnings for linting are coming up in green. Does anyone happen to know either where those warnings are coming from (lsp or treesitter) and how to colorize or highlight them? If I could highlight them I could figure out their highlihgt group 😂


the warnings are from lsp, not sure how to colorize it though


Seems there is Diagnostic{Error,Hint,Warn,Info}, thanks!

James Amberger16:02:51

Is there a consensus around here for Conjure over Fireplace? I’m pretty loyal to tpope (sure I’m not the only one)


To make choice even harder, I can say that I've used vim-iced over fireplace since 2020-01 and I like it a lot. I haven't tried to configure Conjure for my use ever so I can't comment on the differences.

James Amberger16:02:07

Okay, cool. I’ve shaved enough yaks over the past week or so that I’ll chill with Fireplace for now.

James Amberger16:02:38

I do have some questions about whether I am leveraging this repl/editor thing correctly


There is no right answer. They're both great. Use whichever one you like better! 🙂


*They're all great


I will say that Conjure provides a great out-of-the-box experience, in my opinion. @U38J3881W has taken a lot of care to make it so that it "just works" with no configuration necessary. The only effort on the user's part is just reading through the help text and learning the key bindings, etc.

James Amberger16:02:50

But are these packages roughly equivalent? so if I start a “new to repl-ing” thread here should it be fireplace-specific or, not?


When I switched from Fireplace, it didn't yet have async eval, which is now has.


Fireplace, Conjure, Iced, and Acid are all equivalent in that they provide REPL/editor integration. Besides that, there are big differences in the features that each provides.


The overall workflow is the same, though: you start an nREPL server, connect to it from your editor, type code into your editor (usually in a comment block) and eval the code to see the results without leaving your editor

James Amberger16:02:24

so far, if I’m working on a function, I eval the definition and then call it with cqc (fireplace command-line editor

James Amberger16:02:57

but I’m sure I’m missing something, for example if I want to eval some subform in the function that contains a function parameter

James Amberger16:02:15

I mean how would I go about providing argument and then evaluating a subform, and is that even a typical approach


And I'm pretty used to my way of working with REPL over 9 years so any plugin I choose will need bunch of configuration to fit my use and bindings. So I don't know about default vim-iced setup, and Conjure would need configuration just to fit what I'm used to 🙂

James Amberger16:02:57

isn’t that the point of vim, to have things exactly the way you want them 🙂


There isn't much ways around evaling code from defn/let which requires some bindings. Just avoid needing to eval such code. I usually have the function call in a comment or somewhere instead of using comething similar to cqc.

James Amberger16:02:40

oh yeah, that will work in a comment?


(comment (println "1")) yeah cpp would eval the println depending a bit where your cursor is

James Amberger16:02:17

ahh (comment) not ;


If you often need to eval only some part of fn or let, maybe it is good place to split it into a separate fn.

James Amberger16:02:12

is it typical to define functions you’re pretty sure will only ever be called within one other function?


If I'm testing a function that I'm writing, I will sometimes def an example value with the same name as the parameter. For example:

(defn add-five
  (+ x 5))
If I eval the form (+ x 5), it won't work because x isn't defined. Most of the time, to test my function, I would just add this below:
  (add-five 42))
And eval the (add-five 42) expression, which works. Sometimes, if it's a more complex function and I just want to test a sub-expression within the function body, I'll eval, like (def x 42) and then I can eval (+ x 5). It's not always a good idea to do this because you're messing with your global definitions, but it's a useful trick sometimes.

🎯 1

> is it typical to define functions you’re pretty sure will only ever be called within one other function? I think this is very subjective! It depends on who you ask.


I think more about if the function does something useful by itself, than if the fn is called from multiple places. If you have lots of context, separating a part into own fn might not be that clear as you need many parameters. You can also marks functions private so they aren't used from other namespaces accidentally, if they are "internal implementation".

👍 1

IMO, it is a good idea to break up larger functions into smaller ones, even if the smaller function is only called in one place, because it can improve the clarity of your code.

James Amberger17:02:14

Dave, I like it.


+1 for making implementation detail functions private!

James Amberger17:02:52

juhoteperi is that enforced or just conventional


In Clojure JVM side the private functions can't be called directly, compiler enforces that. They can still be accessed using clojure.test util fn or by accessing the fn through the var (#'foo-ns/private-fn ...). In Cljs compiler will print warning, but the function will get called if you run the resulting JS.


@james.amberger if you want to explore that whole "evaluate expressions in a comment block" workflow they are referred to as "rich comments" in the community

James Amberger17:02:28

pretty amazing how quickly people pitch in on here

James Amberger17:02:37

I held off because I don’t really have any other use for Slack, but

James Amberger17:02:50

odds of actually using Clojure for something have definitely gone up


Quick note, if you evaluate the whole comment block it returns nil . You want to usually be evaluating the individual expressions within that comment block