Clojurians Log v2

Seems like clojure-lsp is causing clj-kondo to create cache files in .clj-kondo/cache, which causes a bit of confusion. Maybe this could be placed in something like .lsp/.clj-kondo-cache instead? See the comments on https://github.com/BetterThanTomorrow/calva/issues/917 for a bit more on this.

Or it could make it under .cache like default clj-kondo?

It seems to do that too, in fact. But maybe that can cause conflicts? If clj-kondo is also standalone? Like it currently is for most Calva users.

I would vote for either .clj-kondo/.lsp-cache or .lsp/.clj-kondo-cache

I also think it would be nice to automatically create a .gitignore file inside the .lsp directory that is preconfigured for whatever cache files the lsp creates. I haven’t thought this through a lot though, just seems like a reasonable help to provide when producing hundreds of cache files.

clj-kondo could do this too

https://github.com/clj-kondo/clj-kondo/issues/1113

@pez surely a .lsp directory pattern should be in a ~/.gitignore_global file, like other tool specific patterns.

It feels a bit rude to edit this file, though.

I would not expect a tool to edit any git ignore files (certainly not without prompting me to confirm it's okay).

@jr0cket what about clj-kondo issue 1113? do you think it's bad or good?

Here we have some tools that create directories with files in them in your project, without prompting. They can do this with a bit less disruption by making one of the files tell git what should be ignored. I think that is nice.

So the is a binary (clojure-lsp) that is causing another binary (clj-kondo) to create cache files in the second binaries dot config directory. Is there any reason either binaries dot directory would be committed to a projects git repository? Are these tools dot directories containing config exclusive to a project? Perhaps .gitignore_global and other user level configs are no longer as common as they used to be. That would be a sad loss.

@jr0cket If you can explain why 1113 is a bad idea, I will just close the issue and not bother. Personally I haven't found it a problem to add .clj-kondo/.cache to project .gitignore.

There is code in .clj-kondo that you should add to git

but not the .cache dir

#1113 looks a good idea to me and we could do that for clojure-lsp too

Posted a comment on the issue. I don't get polluting a project gitignore with tooling is valuable. I use the global git ignore file, so wouldn't affect me either way. Although hopefully any cache files are cleaned away at some point to avoid using up file space.

We can also fix the cache folder here to .clj-kondo/.cache or whatever you think its best: https://github.com/clojure-lsp/clojure-lsp/blob/master/src/clojure_lsp/feature/diagnostics.clj#L86 ATM is really pointing to .clj-kondo/cache

I see your point, but most users doesn't even known its possible to add a global_gitignore, and it'd be great to libs like clojure-lsp and clj-kondo just make things work without the need of user change anything, good defaults for a better UX

The suggestion isn’t to use the project’s .gitignore, though. Just so that is clear.

@ericdallo that would be something fundamental missing from a person's skills with git. It is well documented. I did notice that Calva docs do not seem to be aware of the global ignore, so I was going to raise an issue / PR

@pez so clojure-lsp is causing clj-kondo to create extra files and the solution is to creat another file to hide them from git? Is that right?

Not sure it's that fundamental 😕 And if it's possible for the lib fix its own mess (cache dirs) with a .gitignore inside .clj-kondo or .lsp , it seems to me a quick win

clojure-lsp also creates its own files, but yes, it is making clj-kondo create files. What many people will do (I know since it is what happens with Calva) when they see the change list, is to ignore the entire .clj-kondo directory, which is a mistake. They might even use the global gitignore file for this, but regardless, since clojure-lsp knows what should be ignored, it can tell git this.

@ericdallo There lies the problem I suspect.

Yes, I agree with @pez, we known what we need to ignore for sure, so we could do that

Perhaps I don't really understand the problem you are trying to solve. So many things I don't understand about LSP. I am sure you know what you are doing

Released version 2021.01.05-13.31.52 which makes `clojure-lsp` smarter suggesting more namespaces to add when it's a known ns like `clojure.string` or a known `refer` like deftest 🎉 Also, it adds the namespace name to be required now!

It’s time we ask @jayzawrotny if he can craft a logo, me thinks. 😃

That'd be great!

I created a random one on Gimp because we didn't have any 😆

You also created a forbidden one. 😃 (I was asked by Alex Miller to not use the Clojure logo in the Calva logo, and that lead to the awesome Calva logo we have today, by @jayzawrotny).

Oh! I didn't know about that 😞 good to know! If @jayzawrotny can help us it'd be great, otherwise I'll have to create a really random one 😆

Let’s see if he hears we are summoning him. 😃

Whoa. Thanks for this!

I think @jayzawrotny is more active in the doom emacs discord

I'm on that discord server too, I can dm him if he doesn't answer here 😅

He showed up in the #calva channel on this Slack the other day. 😃

That should work, I think

I do use a lock, and it should work cross-process too, but some testing would be nice

Hey there. I’m available and interested, will need some more context though. 🙂

Nice! thanks for that @jayzawrotny I can help you with all info you need 😄

Great! So first question: What would this logo be for? Clojure-lsp?

briefly, there is the https://microsoft.github.io/language-server-protocol/) that was created by Microsft to create a standard on how a language should behave on multiple IDEs soving the problem m languages for n IDEs To do that, there is a server for each language (which calculate and knows how a language works) and the client which are the IDEs (Emacs, VSCode, Sublime Text etc). The logo is for clojure-lsp , which is the server

It'd replace this terrible logo that I created 😂 https://github.com/clojure-lsp/clojure-lsp#clojure-lsp

You're welcome! 😄

What could speak against using the same directory is that clj-kondo starts to do things it doesn’t do otherwise in the presence of the .clj-kondo directory. Not at all sure that matters a bit, just a thing to consider.

clj-kondo uses the .clj-kondo directory to detect the project root (it needs the user to do this) and as a way to let the user say: yes, please fill the cache, at this location

To me starting Calva with clojure-lsp was the first time I ever saw the .clj-kondo directory. 😃

@pez you never used a .clj-kondo/config.edn ??

I think I have once or twice when having had some chat with you. 😃

it's kind of a must if you have custom macros, like these: https://github.com/ericdallo/dotfiles/blob/master/.clj-kondo/config.edn#L10-L17

To me the clj-kondo extensino just works. I love it.

Yeah, IMO if user doesn't even needed to use the custom config.edn , probably means the defaults are very good tuned 😅

Yes, I remember using it for some custom macro in some case. Or, rather, helping some Calva user with it.

clj-kondo is an inspiration when it comes to nice defaults. Ux de-lux.

For the record I haven't used the .clj-kondo/config.edn either, at least not often if so.

Maybe now that there is also #_:clj-kondo/ignore there is less need for it, although I use that as a last resort ;)

Something that'd be great to improve, it's to have a feature like cursive has, where user can tell how the linter should lint an unknown macro, that probably would reduce a lot the need to change config.edn 😉

I'm confused, isn't that what's done in the config.edn currently? How else does a user tell the linter how to lint an unknown macro?

(just curious)

Yes, but user doesn't even need to know about a config file, in Cursive, user interactively select how should lint and Cursive persists it for next sessions automatically

Ohh interesting

@ericdallo that can be done by saving :lint-as in an extra .clj-kondo/lsp-config.edn and then using that as extra configuration

(as to not mess with the user-written one)

Could be solved as that the editor integration writes into the config file, right?

I mean, the use case as such.

hmm, you could also add it to the .clj-kondo/config.edn using rewrite-clj(c) while preserving whitespace and comments

you are probably doing this already a lot in lsp anyway

(I also made a small tool specifically for edn files: https://github.com/borkdude/rewrite-edn)

I never bothered with this, since I hoped editor plugins would do this for me ;)

And I can't possibly make editor plugins for all editors where clj-kondo runs

So I'm happy you are thinking about this

Yes @borkdude I don't think it'd be difficult to implement, maybe the issue here, is that doesn't exists a standard for LSP to do that, maybe we could achieve it with a custom command from LSP though and clients (like Calva), call these custom commands with the user input or something like that

Yeah, this is very editor specific

so maybe it should live in Calva itself

A custom command sounds great though. The editor picks up the user input and uses the command to persist the setting. Something.

Maybe some callback-like thingie that abstracts away the UI part

clojure-lsp uses the workspace/executeCommand for some a bit similar things. wouldn’t need a callback even?

I’ve been away playing Just Dance 2021 with my whole family for a while, so have to admit I can have missed some context here.

the issue being editor specific is that all the logic become responsibility of client and lsp-mode for eample would need to duplicate that, a command in server would centralize that logic only needing the input

Exactly, this could be achieved via https://microsoft.github.io/language-server-protocol/specification#workspace_executeCommand just like we do for refactorings and server-info 🙂

Yeah, I’d like that. Of course could also be a cljc library, but not all editor integrations can easily reach that.

Using clojure-lsp with :emacs: !