This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-25
Channels
- # announcements (4)
- # babashka (58)
- # beginners (21)
- # calva (42)
- # clj-kondo (15)
- # cljdoc (16)
- # cljs-dev (11)
- # clojure (57)
- # clojure-denmark (1)
- # clojure-europe (24)
- # clojure-france (4)
- # clojure-nl (1)
- # clojure-norway (16)
- # clojure-spec (6)
- # clojure-uk (2)
- # clojurescript (19)
- # clr (4)
- # conjure (1)
- # core-logic (3)
- # cursive (5)
- # data-science (2)
- # datascript (6)
- # datomic (3)
- # emacs (4)
- # events (3)
- # fulcro (17)
- # gratitude (2)
- # hyperfiddle (4)
- # introduce-yourself (3)
- # jobs-discuss (2)
- # lsp (27)
- # malli (22)
- # pathom (73)
- # portal (21)
- # re-frame (5)
- # releases (1)
- # vim (8)
- # xtdb (28)
just posted https://github.com/clojure-lsp/clojure-lsp/pull/1471 to add :style/indent
support. it works great, and it has negligible performance impact even when I run against Metabase.
I'm fixing the lint etc.
LMK what you think about the approach to conversion; it's kind of fiddly.
@U45T93RA6 may be interested in that
ah, a possibly-controversial point I just noticed.
:style/indent
is nominally only supported for macros, and the PR respects that.
but cljfmt doesn't care and there are lots of useful :style/indent
s in the wild on defn
s too. one example is Toucan, to get nice
(db/update! SomeModel id
:field 7
:other_field "bar")
I'm ok supporting it for functions, I can't see how one would add a :style/indent accidentally if not for that purpose
agree. my only concern is that they're not namespaced 😞 cljfmt is too naive to understand an indent spec for 'toucan.db/insert!
should be used when (:require [toucan.db :as db]) (db/insert! ...)
if the classpath has 2 functions of different ns with same name and both with style/indent, one of them would use the wrong style/indent right
yeah, that's correct.
the Right Answer is probably to make cljfmt smart enough to understand ns aliases, then it would work unless you :refer
or :use
.
SGTM. I'll look into that as a PR today too; hopefully it's not too hard.
how about I future-proof the PR by making it use macros unqualified, and functions qualified?
hmm, since cljfmt doesn't support that and we don't even know if is easy or even possible I wouldn't suggest do this premature optimization, we could easily change that later after cljfmt changes
https://github.com/weavejester/cljfmt/pull/291 fixes the aliases on the cljfmt side
Thanks for the ping!
Awesome stuff.
Stupid q, is a dynamic require like a top-level (require '[foo.bar :as f])
accounted for?
@UCY0GT0QM I'm about to release a new clojure-lsp version tomorrow, but I'd like to leave this PR for the next one if you don't mind since I'd like to test it in the master a little bit more regarding perf/any issues we may face
sounds good. I can use my local build in the meantime anyway.
Or use a nightly one from #C032YH7P0R2 (compiled with graal) Sounds good, LMK if you will address vemv suggestions or if it's read to one last check
@UKFSJSM38 thoughts on just including the non-macros, with namespacing? it's a tiny change to LSP.
we can avoid the need for the cljfmt fix in most cases with (update cljfmt-config :alias-map not-empty)
, since it's nearly always {}
.
new version up