Cider's namespaces and vars filtered from ns-list and apropos

[ckoparkar]

For clojure-emacs/cider#1564. I still have to write the tests, update documentation etc. But is the basic idea correct ?

And on emacs, we can have a custom var like,

(defcustom cider-filter-prefixes '("cider.nrepl" "refactor-nrepl")
  "Cider middleware would filter out information from namespaces starting with `cider-filter-prefixes'"
  :type 'list
  :group 'cider
  :package-version '(cider . "0.13.0"))

which will be nil, if we want all the internals visible. Also, if we jack-in from cider-nrepl project, we don't have to set it to nil. It picks up the un-inlined versions of deps. But its good to keep it configurable.

Some screenshots;

ns-browser

apropos

If the user types out the entire ns form the ns-browser, he'll still get the vars listed. But thats ok I guess.

[bbatsov]

I would still have the inlided-deps filtered separately for clarity's sake.

[bbatsov]

In general the approach sounds reasonable. Maybe it'd be better to use filter regular expressions instead, so people would have more flexibility. Even this is better than the current situation, though.

[ckoparkar]

@bbatsov Ok. I'll make all the changes today and finalise this PR with tests and stuff. You mean accept regexp from the emacs custom var ?

[bbatsov]

@bbatsov Ok. I'll make all the changes today and finalise this PR with tests and stuff. You mean accept regexp from the emacs custom var ?

A list of regexps.

[bbatsov]

@Malabarba what do you think about the config?

[Malabarba]

I agree with using a regexp, though I have no opinion on whether it's better to have a list or a single one (they're pretty interchangeable).
One thing to keep in mind is that this will be a Clojure regexp, so

1. it won't get any special support in Customize buffers,
2. users will need to know they're supposed to write a Clojure regexp with twice the number of backslashes.

[arrdem]

Is that really a detail you have to ah inflict upon the users? Is it unreasonable to re-compile on the Clojure side?

[Malabarba]

@arrdem
If someone is willing to write a translator, that's fine by me. :-) Won't be an easy task, though.

Still, I'm pretty sure the regexp engines are not identical in terms of features, so we'd still need to tell users some detail about what they can't use.

[bbatsov]

I have no opinion on whether it's better to have a list or a single one (they're pretty interchangeable).

Seems to me a few regexps are more readable than one huge regexp.

One thing to keep in mind is that this will be a Clojure regexp, so

it won't get any special support in Customize buffers,
users will need to know they're supposed to write a Clojure regexp with twice the number of backslashes.

True. I don't think that's a big deal provided it's explained in the docstrings.

[ckoparkar]

Yeah, I agree. A list would be easier to understand. I've tested this with regexps like ".*nrepl", "cider\.nrepl", "refactor-nrepl"

[ckoparkar]

This is just a regex matcher on a list now. But I think this name makes it easier to read functions where this is used.

[ckoparkar]

@Malabarba Changed it :-) . I got an email about your comment. But cannot actually see it on GH. Weird.

[ckoparkar]

I think the comment was on a commit. The rebase must have cleared everything.

[bbatsov]

Apart from the odd test failure, everything looks good to me here.

[Malabarba]

Me too.

[ckoparkar]

Great :-) This can be merged then ? I'll submit the cider PR tomorrow.