This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-04-16
Channels
- # babashka (17)
- # calva (35)
- # clerk (31)
- # cljs-dev (3)
- # clojars (1)
- # clojure (16)
- # clojure-europe (4)
- # clojurescript (38)
- # clojutre (2)
- # cursive (8)
- # datomic (16)
- # exercism (5)
- # fulcro (5)
- # gratitude (3)
- # hyperfiddle (55)
- # joyride (1)
- # lsp (40)
- # off-topic (6)
- # portal (64)
- # practicalli (1)
- # reitit (3)
- # releases (1)
- # shadow-cljs (38)
- # sql (1)
- # tools-deps (8)
- # xtdb (9)
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.
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):
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):
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 🤷
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).
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):
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:
Both are vars from clojure's eyes, so the same for LSP, I don't think we are doing something wrong here
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.
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
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?
what editor?
there are consult-lsp-symbols
for Emacs which uses the workspaceSymbols
LSP feature
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
And friendly reminder that clojure itself has apropos and find-doc built in for exactly this purpose
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.
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
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 :)
@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) 🎉
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
(Thread/sleep)
for example, there is info only about the class name Thread
, nothing about the sleep
😔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)