On 6/23/07, Nick Alexander <[EMAIL PROTECTED]> wrote: > > Maybe. Alex Clemesha wrote a serious doc search thing that > > he showed me once, but he hasn't integrated it into SAGE yet. > > I was getting impatient so I spent exactly one hour to write > > the current "search_doc" function, since it's vastly more > > useful than absolutely nothing (which is all we had before). > > But prettifying, adding context, etc., all takes a lot more > > than one hour to implement, and probably Alex has already done > > it, to some extent. > > Could I see Alex Clemesha's patch for searching docs? I would be a > good referee, in any case.
He never submitted a patch, and I have the impression he isn't going to since, he's mainly work on his own fork of the notebook, and he's very busy with other things. In any case, I've been thinking, and it's probably actually totally wrong to write this documentation searching code from scratch ourselves. There are numerous high-quality third party open source packages that nicely solve the problem "create a nice searchable interface to a collection of static html documents". That's all that is needed for full text search of the SAGE documentation. What we should do is find such a package that is reasonably good and include it in SAGE. Any suggestions? One that I found is called Xapian, which is a C++ library with Python bindings: http://www.xapian.org/ It would be nice if there were an existing pure-python solution that does the job, but I couldn't find anything, which was very surprising. In fact, I would much prefer choosing a 3rd party project for indexing html docs and including it in SAGE to writing our own, since maintenance will be easier, and the quality will steadily improve with no work on our part. Any ideas or suggestions?? > In this vein, I have a soon-to-be-submitted patch that gives SAGE an > apropos command. If you type `conductor**?', SAGE will list all > (callable) objects with conductor in the last dotted name segment > along with short docstrings: Nice! > (Note: many docstrings do not follow conventions!) Fix'em and send me a patch. > The formatting sucks because my SAGE emacs code cleans it up and makes > it pretty. In the notebook, other code should do the prettifying. Yep. > It would be nice to uniformize the web based notebook interface, some > of the Emacs mode I am writing, and the IPython command line. I have > some ideas about how to do this. IPython maintains a history of > outputted objects; it is a hash-like object called Out. I think that > each interface should check Out for objects that could be displayed in > different ways. For example, that apropos command would return an > AproposOutput object, that would have a family of repr-like commands: > repr itself for IPython, repr_html or repr_notebook for the notebook's > fancy html output, and maybe repr_emacs if it should do something > special. If there was no special handling, the repr is shown. > > That seems to generalize the graphics objects already present in > SAGE. What do people think? I'm a little unclear on what you're proposing exactly. I'll have to think about it. William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
