I haven't looked into it personally yet, but I don't think it'll be too daunting. If you'd like to open an issue (if there isn't one already) then that'll help us both track and remember it. I think it's a good idea and feature. I've been trying to rest over the holiday period and was a little burnt out from code so I've not looked too much recently but will try to regularly contribute again soon.

You may be able to hack some Lua together for now that requires conjures modules and pokes functions to send the right nREPL ops, but it's not exactly easy to dive into I guess. It's possible but not straightforward for someone new to the code basically.

I'm going to join the Discord and poke around at this.

Would it be more appropriate to add missing refactor actions via clojure-lsp rather than develop them in a specific tool. I assume there are a lot of refactor tools already available as either Clojure-LSP or even clj-refactor. If refactor tooling is added directly to Conjure, then avoiding some of the conflicts that are common between CIDER and LSP where features cross over would be appreciated.

Having it in LSP would be fantastic

And fitting with my current viewpoint: Conjure is for things that are much better / only possible with a live eval REPL, LSP for almost everything else

Conjure is all about interactivity with a running program, if a running program isn't strictly required for something LSP is always a better fit./

That being said, I could get refactor working in Conjure in an afternoon maybe, I have no idea where to start with LSP

https://github.com/rafaeldelboni/nvim-fennel-lsp-conjure-as-clojure-ide this looks like a great starting point for a nicely integrated Conjure + LSP setup.

I use the two together in my dotfiles too, just important to map things separately and logically

Yes, that is a very good config and what I based https://practical.li/neovim/ book on initially, before adding a whole bunch of other packages (and telescope extensions)

The https://practical.li/neovim/repl-driven-development/language-server-protocol/ have been added under <leader> l which seems reasonable as they go across languages, so if Conjure adds keys under the localleader then there shouldnt be any conflict. The conflicts are more likely to occur with automated actions such as managing intending. I had some 'fun' with CIDER and LSP initially fighting over automatic indenting... it was like the editor was possessed :rolling_on_the_floor_laughing:

this has tipped me over to just backing up my 15-year-old Vim config and starting over with Practicalli.

which led me to a dumb question that isn't mentioned in the neovim config part of the Practicalli docs - if I have a plugin for a color scheme I like, and add it to the use list, it shows up in the list of color schemes. but how do I set the default permanently? I can't see where it's selected. that feels like a common enough thing to want that it should go in the theme docs.

(I eventually got it working with (nvim.ex.colorscheme "codeschool") but I had to dig pretty deeply into it to discover that the nvim namespace is aniseed.nvim, which magically wraps the Lua vim. library, and look up how *that works to call the colorscheme command.)

Ah, that is something I didnt figure out myself, so I'll add that to the book. There is also the lualine theme, fnl/config/plugin/lualine.fnl which can be different or the same as the selected theme.

I use conjure and clojure-lsp ( installed with mason) together. You get all the lsp functionality ( formatting, code actions, clj-kondo diagnostics, completion, etc all for free ) exposed and it works very well with conjure. The only conflict is K which I personally map to the lsp version. I also have the function signature supplied by lsp shown as you type using https://github.com/ray-x/lsp_signature.nvim along with nvim-cmp supplying completion from both conjure and lsp; might be overkill.