This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (5)
- # aws (4)
- # babashka (141)
- # beginners (139)
- # calva (35)
- # cider (5)
- # clj-kondo (27)
- # cljsrn (20)
- # clojure (37)
- # clojure-czech (5)
- # clojure-dev (26)
- # clojure-europe (11)
- # clojure-germany (1)
- # clojure-italy (1)
- # clojure-nl (3)
- # clojure-spec (17)
- # clojure-uk (16)
- # clojurescript (2)
- # conjure (1)
- # cursive (6)
- # datomic (20)
- # defnpodcast (1)
- # emacs (15)
- # fulcro (26)
- # honeysql (2)
- # instaparse (3)
- # jackdaw (4)
- # jobs (2)
- # lsp (70)
- # luminus (2)
- # meander (16)
- # missionary (2)
- # other-languages (151)
- # pathom (6)
- # portkey (13)
- # re-frame (13)
- # reagent (2)
- # reitit (43)
- # releases (1)
- # remote-jobs (1)
- # reveal (5)
- # rum (2)
- # sci (15)
- # shadow-cljs (37)
- # spacemacs (4)
- # tools-deps (8)
- # vim (20)
Released 2021.04.23-15.49.47 : • Improve resolve-macro-as command to check and log if couldn't resolve the macro (c/c @brandon.ringe) • Improve workspace symbol filtering/searching. Now, the sole candidates shown are guaranteed to include all the characters contained in the filter/search string. (kudos to @nicdaoraf) • Add more tokens to semantic tokens: keywords, functions/var usages, java classes, local variables • Bump Graalvm from 21.0.0 to 21.1.0 • Bump clj-kondo to 2021.04.23 fixing some keywords corner cases.
Thanks for this improvement with resolve-macro-as! The error I get when running the command with the cursor not on a macro form is like
Could not resolve macro clojure.core/def for path /home/brandon/development/clojure-test/.clj-kondo/config.edn . Do you think it would be good to say something a bit more specific to the issue, like "No macro was found at the current location"?
I mean, of course, it should be obvious to the user what the issue is, but the error doesn't really point it out, rather it looks more like there's an issue with the config path.
Yes, we can use LSP window/message to log a message to the client, it makes sense IMO
oh, you are right, we are already logging to user, but it's probably too verbose, right? Maybe log that to the clojure-lsp.out and log to user "No macro was found at the current location"
Maybe so. But that first error message doesn't really explain what the problem is. I would say that "No macro was found..." should be logged in clojure-lsp.out too, or at least something that describes the problem better. That first error message makes it look like there's a problem with the config path or something.
> Improve workspace symbol filtering/searching. Now, the sole candidates shown are guaranteed to include all the characters contained in the filter/search string It seems like this is a bit CPU-intensive for longer search queries. I'm doing some benchmarking now and I'll optimize it by using dynamic programming instead of recursion
I'm sorry I got too lazy to benchmark before I made the PR. I've fixed it now (At least 1000x faster now for long-ish fuzzy match inputs) https://github.com/clojure-lsp/clojure-lsp/pull/409
Sorry if I am not finding this in the docs, but is it currently possible to configure navigation on macros that register keywords (e.g.
re-frame/dispatch)? I know this is in the works on Kondo, but remember that it used to be achievable with the old
:macro-defs init option
no problem, the only keyword that will work for this ATM is the
(s/def ::some-key 1)
I think we can just bake in some support for this for re-frame since it's so widely used
one of the problems might be that you can use the same keyword to def multiple things: subscriptions, events, ...?
I can do a quick spot test on the app I have open to see if it yells at me for trying that. I don't think it is typical usage, regardless (although it is good to have all the corner cases covered)
I made that proposal here: https://github.com/clj-kondo/clj-kondo/issues/1211
Right now we have this:
But it might also be interesting to see where you actually subscribe to certain subscriptions and list those. So a more general approach might be useful?
:def: can be added by :hooks using clj-kondo.hook-api/reg-keyword! to indicate a registered definition location for the keyword. Can be truthy, either true or the fully qualified call that registered it.
@ericdallo that can work indeed, but it's
:def that is bothering me, the name never sounded right to me
you don't define, but it's the keyword name that is used to define a
We can stick with
:def and add maybe
:ref for functions that refer to "defined" keywords. Like
so you can have
(s/valid? ::foobar ...) which gives
:ref ::foobar so you know that foobar is being referenced?
How would you call a function to copy a file
foo/bar/baz.txt into a directory
quux/dir so you get
copy is already taken.
Not to derail, but re-frame does let you overload an
id (register a single keyword as an event, effect, coeffect, and/or sub). Additionally, an
id does not necessarily have to be a keyword. The re-frame registry
re-frame.registry/kind->id->handler is just a map where you can look up what is registered to any value
I think the id is intended to be a keyword documentation-wise right? It might just be because of dynamic typing that it can be anything
All the documentation and usage I have read leads you towards using namespaced keywords and not overloading them, but I do not see it explicitly denounced anywhere either
If you look at the doc string for
reg-sub, it says:
so it does admit that the
The three arguments are: - `query-id` - typically a namespaced keyword (later used in subscribe)
iddoes not need to be a namespaced keyword, but it doesn't explicitly say that it can't be a keyword either
@pez I think you're right. babashka.fs is based on java.nio.file but we might be more relaxed... and just do it.