This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-05
Channels
- # architecture (3)
- # aws (4)
- # beginners (100)
- # boot (14)
- # cider (59)
- # cljs-dev (1)
- # cljsrn (24)
- # clojure (53)
- # clojure-dev (58)
- # clojure-italy (2)
- # clojure-spec (1)
- # clojure-uk (25)
- # clojurescript (7)
- # cryogen (1)
- # cursive (1)
- # datomic (9)
- # dirac (9)
- # duct (3)
- # off-topic (52)
- # om-next (3)
- # onyx (42)
- # portkey (28)
- # re-frame (3)
- # reagent (11)
- # rum (3)
- # shadow-cljs (12)
- # specter (7)
- # tools-deps (18)
- # vim (1)
- # yada (4)
The problem with it is that overall complexity of the code rose a lot by adding it, not to mention some features there require parsing all project files which is pretty slow. Thatās why I was wary of relying on it in CIDER itself. If itās usage is limited to locals thatād be fine, though.
(and thereās also the fact that to generate the AST you have to evaluate the code, which not everyone is expecting) š
interesting thought: - apropos - test - ns ops - more? all have ns & var filtering designed in a custom ad-hoc way. It would be really useful to extend apropos to support search-ns being a filtered list based on whether it's a project ns or not, for example.
It's a good opportunity to have ns-vars return vars from multiple namespaces too, e.g.
{:op "ns-vars", :ns-query {:filter-regexps [#"clojure\.core"]}
Get all clojure core namespaces
{:op "ns-vars", :ns-query {:exactly 'clojure.core}}
Only clojure core
{:op "ns-vars", :ns-query {:project? true}}
Only vars in the current project
{:op "ns-vars", :ns-query {}}
All vars
> all have ns & var filtering designed in a custom ad-hoc way. It would be really useful to extend apropos to support search-ns being a filtered list based on whether itās a project ns or not, for example.
Thatās a very good point! Unfortunately the API evolved naturally (chaotically) and we didnāt give much thought to making it uniform. Actually Iāve been thinking about this for a while now both for orchard
and cider-nrepl
and I think itās really important to work in this direction. The workās not much (or complex), but would make the API usage way easier and consistent.
Same goes for refactor-nrepl
- many things there are wildly different from cider-nrepl
and thereās no reason for this difference most of the time.
cider is organic growth, so is orchard š. I suppose there's rarely much motivation to do a sweeping "fix" like this.
I could make it in a backwards compatible way, now that I think about it, only using ns-query if none of the "deprecated" attributes are there.
Iām not very worried about this - updating the client usages doesnāt take much time. Iām willing to deal with that effort in the name of better future for everyone. š
Yeah, if youāre willing to make it work in backward compatible manner thatād be best, although ideally we should also send some deprecation warnings to the clients, so they authors would update them.
Oh wow, I could totally kill test-ns
, as it's just a way of doing (ns/list-vars {:ns-query {:exactly #{'clojure.core-test}} :test? true})
@benedek these changes would also work very nicely with your new op for listing tests
There's one little hack in here for special symbols, but otherwise this is looking to be a fairly clean abstraction.
I'm trying to figure out: A) Whether apropos has much value beyond sorting B) Whether to match the regex behaviour, or to extend it to allow a regex for both doc & name.
hey, i'm debugging an issue with emacs + saving files being slow, and i think cider is to blame -- as soon as i have established some connections, emacs file saving starts using 100% CPU for about 15 seconds
i did elp-instrument-package
on cider, and it looks like cider-resolve-var
has an elapsed time of 13s
Itās strange that so many people started reported issues with dynamic font-locking and dynamic indentation lately - we havenāt really changed them in years.
The interaction between the two is very painful as the dynamic indent is not as fast as the static one.
Thatās one more reminder that we need to cache this info to avoid the excessive calls to cider-resolve-var
.
(basically you canāt know the indentation for something before you āresolveā it - know what it truly is, and thatās not super fast)
Btw, Iāll likely cut the new CIDER release on Monday. If anyone wants to get some last minute fixes in - the weekend is the time to do so. That applies to me as well. š
https://github.com/clojure-emacs/orchard/blob/0e4fde5536c4afe6efd89922213909a442d88a9c/src/orchard/apropos.clj#L48 this looks like something that can be done on the/by the client.
Yeah, definitely. Some things in orchard look odd just because they simply retained semantics of their middleware usage.
I guess youāre referring to the format
, right? No idea why this is done on the Clojure side. Maybe to make the clients have to work less.
That was the only thing I could think of, but it seems like it masks complexity, it stops you from using any of the other flags.
I've got a nice set of tests setup for the var/ns filtering, looks great. Passes the apropos tests too, might go back to those and decide about call signatures, but otherwise looking good.
Oh, there's an apropos test which tests the namespace list, which is gone now. I'll re-implement some of those in terms that make more sense as a whole.