That looks like an lsp client issue to me, either the fold is affecting the text we're being sent or the edit we send back is being applied incorrectly.

Agreed, @U0JAE119P maybe you should open a issue on lsp-mode

I've had this with clj-kondo too. The issue is that if the brew recipe is updated and CI does another release for the same version, the hash of the asset changes... One solution is to run the brew recipe generation again. cc @UKFSJSM38 @U0BUV7XSA @U07M2C8TT

Yeah, I was aware of that, that we were losing the Sha every release, just not sure how to fix the root cause

The issue is that the cirrus CI probably has run twice

but I'm going to make an improvement in gh-release-artifact to prevent doing this

along with creating a .sha256 option

today

nice!

the brew package still needs to updated manually though

Thanks!

@UKFSJSM38 I now added an option :overwrite false - do you want a PR for this? https://github.com/borkdude/gh-release-artifact/commit/add371333253c0c5e87b519bf66e9b1a25160ec5#diff-eb41a1921d745b990c01a7638b50e4689d163bc9b317cc58c60783d4995c5b2aR226

What I'll do myself is set :overwrite false when it's not a snapshot release

So:

(ghr/overwrite-asset {:org "clj-kondo"
                                :repo "clj-kondo"
                                :file file
                                :tag (str "v" current-version)
                                :overwrite (str/ends-with? current-version "SNAPSHOT")})

I now also added a :sha256 true option which uploads .sha256 files like here: https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-22.2.0

I'm using it like this in bb now: https://github.com/babashka/babashka/commit/2dac7847a89dde8b09755076a556a14e066ca11d

Looks great!

Feel free to open a PR otherwise I can take a look at this on the weekend

@UKFSJSM38 What is the condition on which gh-release-artifact should overwrite an already uploaded file of an existing release?

never, always or it depends?

I think only on nightly?

how does your nightly releases work?

Actually, I can't see why there is a case where we want to overwrite at all

right. you use 1 release per nightly version right?

I use 1 release for all snapshots, until I release

the nightly is a GH action called nightly.yml which just does a date and append -nightly so yeah, it should have no conflicts AFAIK

ok then, I'll make it so

I'll also fix the homebrew package

awesome! 🙏

o wait... there isn't a SHA at all here? that is weird: https://github.com/clojure-lsp/homebrew-brew/blob/4071932befe456812f624ddde4bb03f6039d6c1a/clojure-lsp-native.rb#L9

I can fix it manually but I don't know how that happened

yeah, previous release we did the same :/

https://github.com/clojure-lsp/homebrew-brew/compare/main...borkdude:clojure-lsp-homebrew-brew:patch-1

Merged

Tested and works now. cc @U0509NKGK

https://github.com/clojure-lsp/clojure-lsp/pull/1311

Merged, thank you!

nice work!

I don't think clojure-lsp has this, but why do you prefer zprint over cljfmt? I'd like to learn about the differences. (Meanwhile, I'm still using clojure-mode)

TMK zprint has more powerful configuration options and extensive docs. Having said this, I haven't used cljfmt in years.

We don't support zprint ATM, only cljfmt

it would be nice to support both, but one more dep/integration

I would keep an eye on compilation time and binary size. Some libs with dynamic requires can blow that up

https://github.com/greglook/cljstyle was interesting to me, since it seemed to expand on cljfmt

Looks interesting

+1 for zprint from me too! Very flexible and much more configurable. Too much configurable at times, but also has sane defaults like using the community style guide etc.

Haven’t used it via lsp yet, mostly via neovim’s buffer formatting. But nvim 0.8 has native lsp formatting support so would be great! 😄

I use https://github.com/greglook/cljstyle on the command line (it's available as a binary) and included in setup-clojure GitHub Action. Cljstyle was fairly easy to set up with the https://github.com/practicalli/dotfiles/blob/main/.cljstyle, so very small learning curve. I've added zprint as a aliases to https://github.com/practicalli/clojure-deps-edn, although haven't read up enough about zprint to know how to use it, seems quite different in approach (probably just need to spend time reading the docs)

zprint aims to handle adding and removing newlines, which I believe cljfmt/cljstyle does not. It tries to handle produce the same output for a given input regardless of how the input is currently formatted. It’s significantly more powerful and customizable and it’s worked well at Crossbeam (where I work), but it can produce some really odd formatting lol. I go back and forth whether I like it or don’t.

I thought cljfmt already supports removing newlines :thinking_face:

Yes, cljfmt and cljstyle both remove (and add) lines according to the rules set. I found cljfmt a bit draconian by default, ensuring there was only one line between top-level forms. A little to restrictive for me, especially with LSP auto formatting, I quickly modified that rule to a nice 2 line gap, which feels much nicer to work with to me. Zprint seems very powerful indeed and with great power comes a longer time needed to read the docs. Would like to learn more about zprint when I get the time or find a nice blog that specifically covers lining of a Clojure code base. I got the impression from the docs that there are many more uses that zprint can support though.

Yeah, I think we should consider supporting zprint as long term but we can't drop cljfmt because of breaking changes, feel free to create a issue so we can discuss more about it @U6GNVEWQG

https://github.com/clojure-lsp/clojure-lsp/issues/1315 - let me know if you want me to add any additional information 🙂