<div dir="ltr"><div><div><div>I've discussed this with Jonathan on the issue tracker before, but this deserves more eyeballs.<br><br>Don't get me wrong, the Purr Data help browser is really nice, but its keyword search is currently rather limited because it's confined to the help patches in the doc/ hierarchy. Thus if I go looking for, say `packosc` from mrpeach or `seq` from cyclone then it turns up nothing.<br><br>One reason for this limitation is that constructing the keyword index is noticeably faster that way. But it also makes finding stuff in extra much harder, because you always have to go through the help browser's integrated file browser to find stuff. I find that rather tedious. If I don't know *exactly* what external and object I'm looking for then I'm basically lost in the sea of files that lives under extra. So the keyword search fails me when I need it the most. I bet that most serious Purr Data users out there have run into this issue before. I know that my students run into it quite frequently as well.<br><br>Now it isn't a big deal to make the help browser scan all of lib/pd-l2ork when it constructs the index. In fact, it's just a few trivial changes in the JavaScript code in dialog_search.html, you can find the necessary changes here: <a href="https://bitbucket.org/agraef/purr-data/commits/90f7c755">https://bitbucket.org/agraef/purr-data/commits/90f7c755</a><br><br>To my great delight I found that on Linux, this doesn't really slow down the help browser much on startup at all any more. I've been testing that branch for a few hours now. I hardly notice the added delay and I do enjoy that I can search for stuff in extra/ now, as the screenshot attached below readily proves. I'm thinking hard about adding this patch to the JGU packages so that my students can benefit from this as well, even if Jonathan doesn't merge it into mainline.<br><br></div>Unfortunately, the help browser *does* become much slower on the Mac when it is patched up like that (it needs some 10 secs until it's done building the index -- that's on an oldish 2013 MB Pro, but my Linux box isn't much beefier either). I don't understand why that is. Could it be that the node.js file operations are *that* much faster on Linux? That would be at least an order of magnitude, which seems ridiculous.<br><br></div>What are everybody's thoughts on this? Would you prefer a help browser that's slow on startup but then offers a better keyword search? Or maybe anyone has an idea on how to speed it up some more on the Mac? Jonathan, maybe the index could already be constructed once in the background while Purr Data is loading, so that it's ready to go when it's needed?<br><br>Any and all comments and ideas are very much appreciated. I really think that this is an important area where Purr Data definitely needs to be improved.<br><br></div>Albert<br><div><div><div><br>-- <br>Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email:  <a href="mailto:aggraef@gmail.com">aggraef@gmail.com</a><br>WWW:    <a href="https://plus.google.com/+AlbertGraef">https://plus.google.com/+AlbertGraef</a></div></div></div></div>