Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

passing regex directly to cider-browse-spec-all #2163

Closed
qq00 opened this issue Jan 14, 2018 · 6 comments
Closed

passing regex directly to cider-browse-spec-all #2163

qq00 opened this issue Jan 14, 2018 · 6 comments

Comments

@qq00
Copy link

qq00 commented Jan 14, 2018

problem

we should have something like cider-browse-spec-all which takes a regex as an argument (instead of querying the user for it)

this is so it is easy for users to say "show me all specs in src/" instead of showing all specs in clojure.core + included libraries

discussion

me:: the problem I was running into with spec ... was that it was showing me all types of specs from clojure core + external libraries

@bbatsov: Yeah, that totally makes sense. We should add some filtering for the specs that come outside the project. Please, file a ticket for this. Should be easy to do IMO.

current solution

(assuming that all src/ namespaces start with "aa.")

("j" (my-cider-browse-spec-all "aa\."))
(defun my-cider-browse-spec-all (filter-regex)
  (interactive "P")
  (cider-ensure-connected)
  (cider-ensure-op-supported "spec-list")
  (with-current-buffer (cider-popup-buffer cider-browse-spec-buffer t)
    (let ((specs (cider-sync-request:spec-list filter-regex)))
      (cider-browse-spec--draw-list-buffer (current-buffer)
					   (if (string-empty-p filter-regex)
					       "All specs in registry"
					     (format "All specs matching regex `%s' in registry" filter-regex))
					   specs))))

@bbatsov
Copy link
Member

bbatsov commented Jan 14, 2018

@jpmonettas Can you take a look at this? I think we should definitely add some way to filter out non-project specs. Potentially we can have an inverse filter as well.

@jpmonettas
Copy link
Contributor

jpmonettas commented Jan 14, 2018

@bbatsov the problem with specs is aren't attached to any project, namespace or file so you can't tell where does it come from.

I can't figure out any hack for this either given that keywords ns are not clojure namespaces.

For @qq00 use case maybe #2165 works.

jpmonettas added a commit to jpmonettas/cider that referenced this issue Jan 14, 2018
jpmonettas added a commit to jpmonettas/cider that referenced this issue Jan 14, 2018
@bbatsov
Copy link
Member

bbatsov commented Jan 15, 2018

Thanks for the fast response here!

@bbatsov the problem with specs is aren't attached to any project, namespace or file so you can't tell where does it come from.

I don't quite get this - aren't specs usually attached to namespaced keywords? Can't we used this?

@jpmonettas
Copy link
Contributor

jpmonettas commented Jan 15, 2018

Thanks for the fast response here!
You are welcome

I don't quite get this - aren't specs usually attached to namespaced keywords? Can't we used this?
@bbatsov We can but will not be very accurate, for example:

  (ns geometry-project.core
    (:require [clojure.spec.alpha :as s]))

  (s/def :shapes/triangle (s/cat :base int? :height int?))

now if we are looking at the registry we will see a :shapes/triangle spec

(meta (s/get-spec :shapes/triangle)) ;; => nil

but what project it belongs to?

@bbatsov
Copy link
Member

bbatsov commented Jan 15, 2018

I see your point. I was under the impression people often did it like this:

(ns geometry-project.core
    (:require [clojure.spec.alpha :as s]))

  (s/def ::triangle (s/cat :base int? :height int?))

@jpmonettas
Copy link
Contributor

Yeah I think most people does like that, but have also done the other way so don't know if that feature is a good idea.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants