The highlighting seems a bit different with the LSP server. Notice how the locals are highlighted along with the adjacent bracket. But the underlining is correct. Is it something that could be fixed on clj-kondo's side, or is it an issue with LSP?

This is probably the plugin. clj-kondo is unaware of the editor it's used in

I'm not too familiar with the plugin itself. I don't even know how to build it: https://github.com/gtache/intellij-lsp/issues/122

But I think it's possible to build a standalone IntelliJ plugin from it. So if there will be someone stepping up and tweaking the necessary stuff, it can be a better experience maybe. And there can be a clj-kondo IntelliJ extension in the Jetbrains marketplace

hello, I'm running into linter error, but I don't understand why,

can't parse name_of_file.clj, no conversion to symbol

someone here can give me a hint?

@d.ian.b can you give more context?

can you make a repro?

I'm running:

clj-kondo --lint src --config '{:output {:format :json}}' 

the linter is accusing this can't parse for every file on the repository

and joker does not give me any error

@d.ian.b can you make a repro that I can run locally? using the information you gave me I still can't reproduce it

what version of clj-kondo are you running? what OS?

clj-kondo version: 2019.11.23-1

OS, both in ubuntu and manjaro

the can't parse error is thrown here: https://github.com/borkdude/clj-kondo/blob/2889dff5f3a1d5691ca17e81ab33d624a3376d3d/src/clj_kondo/impl/analyzer.clj#L1479

I'll see here this

I don't know where the -1 comes from in the version. I didn't release that: https://github.com/borkdude/clj-kondo/releases

It's from the packager, arch in particular

i.e., the pkgrel

it's only for the OS, has no relation to what you have released 🙂 which is 2019.11.23

@d.ian.b Try to narrow down the issue by linting only one file from the directory.

And run with CLJ_KONDO_DEV=true that might give you some more info

It's useful if the package meta around the release has changed, i.e., maybe a new depends or arch or url, but the underlying version of the package is the same, i.e., if you where to change the URL to ' then I would change the pkgrel to 2, but keep the pkgver to 2019.11.23, so then what would be installed would be 2019.11.23-2

🙂

@d.ian.b and if possible, try to isolate the case to the smallest piece of code that still triggers the error for you and post it here.

I'll try this

@d.ian.b Do you get the same error when you try to lint an empty file, e.g. put an empty file src/foo.clj in your project

and then run clj-kondo --lint src/foo.clj

I couldn't reproduce the error =<

so the error is gone now?

no

foo does not in the error

but other namespaces are in error

every one another

every file

can you paste code from such a file into foo.clj and then see if that produces the error?

and if so, remove some code, lint again, until you see no error, and paste the smallest bit of code that still produced the error

OK, I'll try =)

I wonder if something like (def x (function-call ...)) should be linted

the amount oif hours wasted because of weird behaviours of things that should have been a defn but were a def is incredible

and they are usually bugs that only happen after a while in specific conditions, so if it's not actually a "simple" constant, should you really use def?

@andrea.crotti I do that quite often

at least, I think I do. I'll keep it in mind

well in many cases it's safe to do so

(def init-in (fn []
               #?(:clj (-> (.StringReader. "")
                           clojure.lang.LineNumberingPushbackReader.))))

(def init-out (fn [] (new #?(:clj .StringWriter
                             :cljs goog.string/StringBuffer))))

(def init-err (fn [] #?(:clj (.StringWriter.))))

(def in (vars/dynamic-var '*in* (init-in)))

(def out (vars/dynamic-var '*out* (init-out)))

(def err (vars/dynamic-var '*err* (init-err)))

but when it's not you can end up with some really weird bugs

I was taking more about things like (def truncate-db (jdbc/execute conn "TRUNCATE TABLE x"))

which in this case it's clearly a problem of course, but it's not always so clear

yeah, it's quite impossible to know when it's not intended I think

yeah it's tricky

@borkdude could you do some linting for hodur files?

haha

it's another request 😃

what is hodur?

I'd guess https://github.com/hodur-org/hodur-engine

there was a talk on it at Clojutre

I need examples of what's currently not linted correctly about this library in a Github issue. Input + current errors + expected solutions.

ok, I'll do it later! 😃