[L2Ork-dev] Improving the help browser (help index)

[Albert Graef]

I've discussed this with Jonathan on the issue tracker before, but this
deserves more eyeballs.

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.

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.

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: https://bitbucket.org/agraef/purr-data/commits/90f7c755

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.

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.

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?

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.

Albert

-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20180320/5ca2d3f8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: help-browser.png
Type: image/png
Size: 36508 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20180320/5ca2d3f8/attachment-0001.png>