Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Add 'apro' variant of 'apropos' that returns symbols with namespaces #107
This is probably not in a form that you would want to include, if you are interested in including it in the first place. Suggestions for changes welcome. No problem if it isn't of interest. Just close the issue.
In particular, I was guessing on how to make symbols usable in reply, like help and cdoc.
Examples of output below. Compare against output of similar apropos calls for the difference.
user=> (apro "replace")
clojure.string=> (user/apro "replace")
Sorry for taking awhile to get back to you on this. I do like this better than the default behavior of
I'm all for this patch in general. I do feel like the naming is a little awkward; how would you feel about something like
I'm happy to merge this and update the naming myself, just wanted to get your thoughts on that idea first.
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
No problem on the response time. One of the reasons I submitted it to reply was that I suspect it would take months to get into clojure.repl, if it ever did. I can submit it there, too, if you'd like it to have a chance of eventually being there.
I have no problem with find-var as a name for this -- apro was simply intended to be similar to the existing apropos but shorter to type.
A quick question: Would you also be interested in something like find-doc, except it only prints out the lines of doc strings that actually match, rather than the entire doc strings? The output of find-doc can be quite long and it isn't always clear from the output where the matches occur.
OK, great. In that case I'll merge this and do the naming update before a release. I'll be sure to take a close look at the exporting, too - in particular, I'm not certain but suspect
And I would personally love to see a clojure.repl patch for it. I consider it to be a bug that
Yeah, I agree find-doc's output is hard to parse. My main concern there would be not having the context from other lines of the docstrings. I'm imagining that an IDE might do this by highlighting the matches. We could actually do something similar with ANSI codes:
(defn highlighted-find-doc [search-term] (println (clojure.string/replace (with-out-str (find-doc search-term)) search-term (str (char 27) "[32m" search-term (char 27) "[0m"))))
That'll need some modification for the regex side of
I will submit an enhancement ticket for clojure.repl, too.
Regarding the color highlighting, my first question would be how to do it in a way that works as portably as reasonable. I guess reply is not used from within Emacs, Vim, etc. when they do things like Emacs's nrepl-jack-in?
Even if reply isn't used in those cases, there are many different terminals with different escape codes around, which is exactly why things like Unix termcap were created. It looks like there are one or two Java libraries that wrap termcap, but as native libraries, which isn't so nice for distributing within reply. Lanterna is pure Java -- it doesn't work across as many different terminal types, but it looks like most of the common ones in use on Linux today:
Ah, good point, I was only considering the frontend side of reply. I guess people do use the initialization stuff from other clients, when they connect to a lein repl.
The portability stuff I hadn't thought through either. I think Lanterna is really interesting, but probably a bigger overhaul than I'm ready to undertake right now (and may be an either/or proposition with jline).
Thanks for the input!
Thanks. I think that makes sense. I'd like to eventually have the option of automatically
This initialization stuff is pretty hairy; needs to be simplified pretty drastically after I get the latest big jline refactor tested and released.