Just confirmed the issue, please open a issue on clojure-lsp

Done: https://github.com/clojure-lsp/clojure-lsp/issues/1165

https://github.com/clojure-lsp/clojure-lsp/issues/1163

But if I use / in Clojure the second one becomes part of the name. And that's totally fine for my uses. I don't need to separate it, it's an identifier

This is from babashka:

bb -e '(name :hello/dear/world)'
"dear/world"
bb -e '(namespace :hello/dear/world)'
"hello"

Don't:

$ plk
ClojureScript 1.10.914
cljs.user=> 'foo/bar/baz
Syntax error reading source at (<cljs repl>:1).
Invalid symbol: foo/bar/baz.
cljs.user=> :foo/bar/baz
Syntax error reading source at (<cljs repl>:1).
Invalid keyword: :foo/bar/baz.

Oh, why does CLJS do that... hmm 😕 I don't use symbols though (phew, dodged all these compilation errors). Only keywords :thinking_face:

bb -e "(namespace 'hello/dear/world)"

1: (namespace 'hello/dear/world)
                               ^--- Invalid symbol: hello/dear/world

So um... I'll ask about this in Clojure then 😕 Maybe they'll do some kind of a patch or maybe it will be marked as "intended". It's not good that the implementations allow different things.

Yeah, I'm not sure it's a issue on clojure-lsp as you opened https://github.com/clojure-lsp/clojure-lsp/issues/1163 @invertisment_clojuria

This is my issue 😄 I created it differently but then as I was instructed that / is not allowed I changed the issue.

Previously I created this issue to indicate that I want to type more than one / and expect the highlighting errors not show up. But after getting more info I changed the issue into "add a new warning" and I think I can't remove bug tag.

hum, we manually edit the clj-kondo file, probably a bug on clojure-lsp indeed

could you confirm if it doesn´ t remove comments if inside the map?

let me check!

it leaves comments inside of the map:

$ git diff
diff --git a/.clj-kondo/config.edn b/.clj-kondo/config.edn
index 1a82492e5..88ff1fd1e 100644
--- a/.clj-kondo/config.edn
+++ b/.clj-kondo/config.edn
@@ -1,8 +1,8 @@
-;!zprint {:format :off}
 {:lint-as {honeysql.helpers/defhelper clojure.core/def
            honeysql.util/defalias clojure.core/def
            ; example comment in test
-           crossbeam.utils/when-let* clojure.core/let}
+           crossbeam.utils/when-let* clojure.core/let
+           clojure.test.check.clojure-test/defspec clj-kondo.lint-as/def-catch-all}

alright, please open a issue, it should not be that hard to fix (if you wanna https://github.com/clojure-lsp/clojure-lsp/blob/master/lib/src/clojure_lsp/feature/resolve_macro.clj#L43)

This is not specified in LSP spec, so I think each editor would need to implement/handle manually

Could you check https://clojure-lsp.io/troubleshooting/#server-log?

It doesn't say anything about formatting. It mostly says about published diagnostics and it has a couple of warnings about clj-kondo. But other than that it looks clean. Does it log formatting attempts? Maybe it means that my config doesn't try to ask for formatting? It has this too but I'm not sure it means anything:

2022-08-01T18:55:52.998Z  DEBUG [clojure-lsp.nrepl:21] - nrepl not found, skipping nrepl server start...

yes, it logs formatting attemps, so probably your editor is not calling lsp formatting

I found the problem. When I have a non-clean working directory and I start a new LSP server then the formatting doesn't work.

try getting <https://clojure-lsp.io/troubleshooting/#client-server-log%7Cclient&lt;-&gt;server> logs

Because I ran git stash -u and then reran nvim and then formatting worked. What's weird with this is that the file that I was formatting was not changed and should've probably compile. I'll try to get the logs.

I have the log. Do you have a specific text that I should look for?

Check if client is sending textDocument/formatting , if no, it's a bug on nvim

I'd suggest asking if anyone on #vim have this behavior

It has the formatting messages:

[DEBUG][2022-08-01 22:10:57] .../lua/vim/lsp.lua:1023	"LSP[clojure_lsp]"	"client.request"	1	"textDocument/formatting"	{  options = {    insertSpaces = true,    tabSize = 2  },  textDocument = {    uri = "file:///home/martin/aaaaaaaaaaaaaaaaaaaaaaaaa.clj"  }}	<function 1>	3

is that uri correct? I suggest you try in a real project, not a single file

There is client.request and then there is rpc.send This is a real and quite large project, I just removed the filename. That URI is correct, if I open it in Firefox it opens the file. This is that URI but with removed intermediate package names:

file:///home/martin/Documents/dev/aaaaaa/aaaa/test/aaaaa/aaaa/crud/queries/aaaaaaaaaaa_test.clj

Never saw this behavior, since server is not logging formatting, I still suspect the request is not being sent to server

Maybe it's logging the formatting, I just didn't look for it. There are places with huge chunks of code. I didn't talk about them. There is the textDocument/didSave and textDocument/didChange which have a lot of code. But textDocument/formatting are very small and without actual code. So should formatting one have my file or should be some kind of the other request?

formatting should specify which file should format, passing the uri

But this is not it?

[DEBUG][2022-08-01 22:10:57] .../vim/lsp/rpc.lua:347	"rpc.send"	{  id = 4,  jsonrpc = "2.0",  method = "textDocument/formatting",  params = {    options = {      insertSpaces = true,      tabSize = 2    },    textDocument = {      uri = "file:///home/martin/Documents/dev/aaaaaa/aaaa/test/aaaaa/aaaa/crud/queries/aaaaaaaaaaaa_test.clj"    }  }}

yep, that looks correct

So anyway. I tried to stash all my files and I think that some kind of initialization prevents the server from formatting the file. Because right now I have a codebase that is dirty and broken. And it doesn't work right now. But when I stashed the changes and restarted then it worked. But it's not this file that's broken. I think something is still broken from my refactoring but I don't know where so I haven't fixed it yet. But it's probably bad that it doesn't format if something somewhere else is broken.

yeah, it's hard to debug, maybe try in a sample repro where I can try too

Ok, I'll try

I can't make a repro. I tried to import nonexistent function, I tried to require a file that has bad ending parens, I tried cyclical dependency and also nonexistent ns. All of these worked. I don't know why my current project doesn't. I'll try to look for what could be different. But now I have to go to sleep. I hope I'll notice what this is.

When I stash and start-up vim then it works. Then when I unstash it stops working with the same LSP server. So it's not tied to start-up of LSP server. Maybe that's a clue. I mostly have symbol and namespace import renames. I also found that in both cases the tests pass and repo compiles just fine. So it's something weird 😄 Removing of .clj-kondo dir did nothing. Is there other cache I could delete? Removing .lsp and restarting also did nothing.

This test code snippet breaks the formatting:

(deftest magic-test
  (testing "should delete stuff"
    (testing "id check"
      (is (= {:aaaa-aaaaa/aaa-aaaa-aa [:aaaaaaaaa/aaaa-aaaaa/aaa-aaaa-aa]}
             (->> (core/foo
                   [:aaaaaaaaaaa/aa-aaaaaa-aaaaaaaaa :aaaa-aaaaa/aaa-aaaa-aa])
                  ::aaaaaaaa-aaaaaaaa/aaaaaa
                  :aaaaaaaaaaa/aa-aaaaaa-aaaaaaaaa))))))

{:aaaa-aaaaa/aaa-aaaa-aa [:aaaaaaaaa/aaaa-aaaaa/aaa-aaaa-aa]}

(deftest magic-test
  (testing "should delete stuff"
    (testing "id check"
      (is (= (->> (core/foo
                   [:aaaaaaaaaaa/aa-aaaaaa-aaaaaaaaa :aaaa-aaaaa/aaa-aaaa-aa])
                  ::aaaaaaaa-aaaaaaaa/aaaaaa
                  :aaaaaaaaaaa/aa-aaaaaa-aaaaaaaaa))))))

I added a link of this chat into this issue: https://github.com/clojure-lsp/clojure-lsp/issues/1163 I think this is connected.

yep, double quotes should cause issues on lots of libs :) in this case, https://github.com/weavejester/cljfmt, which is what clojure-lsp uses.

But it works on CIDER just fine. That's weird :thinking_face: I think you do some kind of parsing. Also your linter fails.

cider does its own formatting rule, clojure-lsp delegates to cljfmt to format, so this would be needed to be fixed there, and about the lint on clj-kondo, if @U04V15CAJ agree this should be fixed...

Yes but... https://develop.spacemacs.org/layers/+lang/clojure/README.html

> if @U04V15CAJ agree this should be fixed. Can you give a summary of "this"?

Is this one by default? Also, we would need to debug if cider is calling the exact same function of clojure-lsp.

> Can you give a summary of "this"? About making clj-kondo understand double slashes

> About making clj-kondo understand double slashes and complaining about them

sure

There is also a comment from Alex Miller that even though CLJ supports the _/__/__ for symbols and keywords right now it's best for futureproofing to not use it.I added it into the github issue.

CLJ doesn't support it, it just lets it slide it because it doesn't check the input

I used it for quite some time and I didn't have any problems. The second / happily goes into the name of the keyword and symbols like that are allowed too. I had literally no problems with it except when I asked why LSP has problems. It works flawlessly in CIDER for CLJ -- both symbols and keywords. Also the doc is vague on this so they probably didn't care at the time they wrote it. But if it gets added into the linter then it's the standard (except in CIDER).

I've explained my point several times to you know. Although in some cases you might get away with it, it is not supported by Clojure. Don't do it.

My point is not to do it but figure out why it doesn't work and I know now. I already used it for several months and I'll do my refactoring. I can't do it immediately, there is quite a bit of code. It's not that I somehow can't refactor but it takes time and obviously why refactor when I didn't even know it's a thing.

I think something is off. If I run this command then the output already contains a message about my bad keyword:

clj-kondo --lint src/ | grep keyword
src/.../.../core.clj:104:1: error: Invalid keyword: my/fancy/bad-keyword.

clj-kondo --version
clj-kondo v2022.06.22

It could be a analysis error from kondo side so clojure-lsp is not showing all possible lint issues

I think that in my github issue's screenshot it's the same thing that's happening. Keyword parsing fails and it cascades into a different failure, in that case it thinks that the first value of the map has a newline inside (IMO this is what's broken).