Fork me on GitHub
#lsp
<
2023-04-16
>
Martynas Maciulevičius07:04:20

I think that semantic highlighting loses its purpose when it highlights definition of hi in the last line in the same way as a function call. I already know that start is a function and hi is a constant (but not a map/set/etc). But semantic highlighting returns that both of those are function and I colored them in red. And now everything that is a symbol is red. I don't want them to have a single color. I think that this kind of highlighting only creates harm without any good outcome because there is no semantics encoded in it but only that it's a symbol. If I choose to use a color for functions then subs is red and hi is red too. And that makes my code completely unreadable. I think highlighting should provide different colors and not color everything in a single color.

Martynas Maciulevičius07:04:44

With this highlighting I get this kind of code which is completely unreadable (I chose red to show that it's one color) (also def is orange and it's what I wanted but everything that is red is function that comes from LSP's way of semantic highlighter. I think that magic-number-1 shouldn't be marked as function and it shouldn't be colored in red color):

Martynas Maciulevičius07:04:17

And in my Spacemacs I at least have this which is a little more readable (don't mind the number constants and def because I don't talk about them right now) (also I didn't make everything red but they don't even try to highlight functions "properly" by showing what is a function and what is a var):

Martynas Maciulevičius07:04:22

So I think it would be a good effort to color symbols if they would be functions but if they aren't checked to be functions then there is no point to mark them as functions 🤷

Martynas Maciulevičius07:04:52

I don't know what could be a fix for this but I think that if people also edit other languages with same color schemes then they probably will have to choose a color scheme for each language separately. And... to support it they could opt to simply run two editors instead of editing everything in a single editor. I think this is a oversight in what LSP's semantic highlighting was supposed to deliver. If you don't analyze every variable if it's a function then you can't actually deliver useful highlighting tokens to an editor. This doesn't work. Of course -- you deliver information whether a symbol points into a macro and this is very valuable. But by saying that everything else that is a symbol is a function you force people to design their color schemes for other languages in ways that have Normal text for function calls (i.e. not colored).

Martynas Maciulevičius07:04:59

This is how it would look like in the same editor that I was trying the LSP but when I shut down LSP and enabled the original highlighting (these yellow tokens are all hardcoded in the syntax regex plugin):

Martynas Maciulevičius08:04:18

It's mitigated when I have a function (and this is how I'd use it the most). But well you could also check if the reference points into a constant and not a function. Or you could do a check that checks whether it's a local namespace's symbol but that sounds kind-of weird to do it. LSP highlighting when it's a function with params:

ericdallo12:04:37

Both are vars from clojure's eyes, so the same for LSP, I don't think we are doing something wrong here

Martynas Maciulevičius13:04:13

I know I try to push here but I also want to know what's doable and what's not. This is certainly not possible with regex matchers as you also correctly find which symbolsvars refer to macros. But maybe it could be better. Probably you're right.

ericdallo13:04:03

Probably possible, but a def could point to a function, or be a function, so everything are vars, it's misleading handle the code differently

witek16:04:14

Is there an Emacs command to list all vars/definitions of the whole project? Preferably in the completion buffer, so i can search for one and directly jump into it?

ericdallo16:04:29

what editor? there are consult-lsp-symbols for Emacs which uses the workspaceSymbols LSP feature

👍 2
borkdude17:04:22

you may also be interested in https://github.com/borkdude/quickdoc which generates an API.md page from your project - not exactly what you asked for though

dpsutton17:04:02

And friendly reminder that clojure itself has apropos and find-doc built in for exactly this purpose

borkdude17:04:13

but no source links

witek17:04:36

Thank you, but ericdallo's suggestion was the right thing. I am looking the quickest way to jump to a function in my project. Sadly it is so big that consult-lsp-symbols needs about 5 seconds to show up.

witek17:04:54

Will have to keep using two steps: 1. jump to file 2. jump to definition.

mpenet19:04:06

xref-find-apropos kind of (but it’s slow too). the quickest (for me) is really just consult-git-grep, it’s not exacty list/jump to def(n) but with some clever input it can become that

ericdallo19:04:46

clojure-lsp I'm working in improved java support, check hover docs showing java signature + docs! A 2 years old complex https://github.com/clojure-lsp/clojure-lsp/issues/204 There is a lot to work still both in clojure-lsp and clj-kondo, but glad the basic it's working :)

❤️ 12
👍 4
💯 8
ericdallo19:04:17

@U04V15CAJ I ended up using javaparser in clj-kondo, the code was simple and with that kondo will support all java analysis, both .class (via ASM) and .java (via javaparser) 🎉

ericdallo19:04:36

One thing we would need to improve in kondo to have a almost perfect UX, is to provide mode details for instance-invocations and java-class-usages buckets, like the class name and the name, things I think we have now available

ericdallo19:04:20

(Thread/sleep)
for example, there is info only about the class name Thread, nothing about the sleep 😔

ericdallo19:04:16

There is some reflection issues for me to fix yet

borkdude19:04:53

Probably more like build time options

To see how the classes got initialized, use --trace-class-initialization=com.github.javaparser.ast.body.FieldDeclaration,com.github.javaparser.ast.body.ConstructorDeclaration,com.github.javaparser.ast.comments.Comment,com.github.javaparser.utils.Utils,com.github.javaparser.ast.body.BodyDeclaration,com.github.javaparser.ast.body.TypeDeclaration,com.github.javaparser.ast.expr.SimpleName,com.github.javaparser.utils.LineSeparator,com.github.javaparser.ast.type.Type,com.github.javaparser.printer.configuration.DefaultPrinterConfiguration$ConfigOption,com.github.javaparser.ast.body.MethodDeclaration,com.github.javaparser.ast.body.CallableDeclaration,com.github.javaparser.ast.Node,com.github.javaparser.ast.body.VariableDeclarator,com.github.javaparser.ast.Modifier,com.github.javaparser.printer.configuration.Indentation$IndentType,com.github.javaparser.ast.body.Parameter,com.github.javaparser.ast.body.ClassOrInterfaceDeclaration
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.UserError.abort(UserError.java:73)

ericdallo19:04:13

yeah, I forgot to check if javaparser is compatible with graal, I hope so 🤞

borkdude19:04:39

I don't understand why those classes must be initialized at build time though, they only seem to be used in defns

ericdallo19:04:07

yeah me too, I suppose javaparser uses them statically?

borkdude19:04:26

it adds roughly 3mb to the clj-kondo image size

ericdallo19:04:07

that's bad, but I hope it's not a big deal

borkdude19:04:19

no, it's ok I think

ericdallo19:04:48

Cool, with that we would officially support all java stuff in kondo we want :)

borkdude20:04:03

I'll check the PR tomorrow or so

👍 2
Noah Bogart22:04:04

This is so dang cool

🎉 2