A quick look at Dash for [OS X] documentation browsing
notesfromandy.com
notesfromandy.com
When searching for a method on a class, you can do a partial string of the class then use alt + up / down to quickly scan through method names. What'd be useful also ( and I think this was an earlier feature ) is to be able to have the second word look at class/instance methods first before then resorting to google / stack overflow.
Maybe there's a way to do these things, but I didn't see them in the help pages after a quick perusal.
So, pretty dang nifty, maybe worth $30 to me. Definite sale at $15 or after the next time I get seriously frustrated by how man pages work (that hasn't happened in a while though)
edit: Suggestion for the search box: Start the search from the current position within the document rather than resetting to the top of the page. Especially given the subtle visual of the scrollbar, it'd be nice to not have searching cause the document to jump around all over the place.
Regarding your specific problem, read(2) should have had "read" as the top result. I'll look into it and try to figure out where the sorting fails. Thanks for reporting!
However, I do not like how it deals with matches in multiple docsets.
E.g. when you search for "String" and have the Ruby and RoR docsets enabled, then it will always show the RoR one first. The only way to switch to another one seems to be by clicking that microscopic icon in the list.
Possible fixes (ideally implement them all):
1. Optionally show all hits separately in the list (then I can just click directly on the Ruby or RoR version)
2. Display a toggle-bar at the bottom of the window where I can quickly enable/disable any docset. Most of the time I'll only want to search in one particular docset anyway.
3. Provide large buttons at the top of the right pane for each matched docset, to easily switch to a different version (Ruby, RoR, ...).
Other than that: Great work. If this issue gets fixed I could see this tool becoming part of my workflow (and paying for it).
Currently you can also use docset keywords to search a specific docset. Check out Preferences > Docsets > Enable Docsets.
Yes, showing them separately seems like the easiest permanent fix. Ideally with the docset toggle-bar, so the noise can be cut down quickly when zero'ing in on one language for a few minutes (that's what typically happens in my workflow; digging into coffeescript for a while, then some ruby, then again coffee, etc.).
Still, a minor annoyance.
I summarised some of the problems I had when I first opened the app.
- Where do I search? There are two search fields with ambiguous placeholder texts.
- Where is the documentation? I expected to be able to click on a button called "Ruby" and browse the Ruby documentation.
- The double function of the side bar (perhaps the whole app) confuses me. I expected it to be mainly an app to browse/look up documentation. After some time I figured out the app serves the function as snippet repository as well. What confuses me most is that once you search for documentation, the snippet part of the app completely disappears.
Personally I wouldn't have put in the snippet part. It's, in my opinion, the job of a text editor or IDE to manage snippets. Alternatively a dedicated app such as Notational Velocity could be used to manage snippets.
I hope you find this comment useful, as it's definitely not intended to shit on your app :)
Though the interface could do with some work.
Two feature suggestions:
1) Search inside a selected docset? Like only in iOS or only in Wordpress.
2) Show the index of a selected docset, for API exploration.
As noted by another commenter, I too use Alfred for site-specific searches but this looks much more powerful.
I just set up a custom search using the url: dash://{query}
And a few specific custom searches like: dash://css:{query} or dash://php:{query} if I want to get to something specific.
It seems the System Service for searching in Dash wasn't working in IntelliJ IDEA so I set up a hotkey instead in Alfred to search Dash with the selected text. Works great.
I'll probably never even touch the snippet functionality, but I'll buy it when it is released for the speedy searches.
The one huge negative of OSX documentation is the lack of commenting and inline code samples like you'd see with say, the Django docs.
And that's why I'll be paying for it, because you're not making it annoying in the first place. :)