On Thu, 15 Aug 2013 08:52:11 -0700 (PDT) "Edward K. Ream" <[email protected]> wrote:
> Rev 5906 completes the work of editing more than a year's worth of emails > into preliminary docs of features, especially plugins. I'm not that familiar with Leo's docs. stack, but I'm wondering where the canonical version of plugin docs should be, and vote for the doc string of the plugin. .../leo/doc/plugin_catalog.py can then pull them all together. There are over 100 plugins, so this must be something that should be automated / data driven rather than manual document maintenance driven. Here's the current output: http://greygreen.org/tmp/plugin_docs.html Even copy / pasting from the plugin doc strings to the main docs seems like a violation of the DRY principle. The part that would have to be in the main docs because it doesn't fit in individual plugins would be some overview of plugins, like... There's all sorts of functionality in plugins, some of them are major add-ons / capabilities, like valuespace, richtext, printing, todo, etc. and some are long forgotten experiments which probably don't work anymore. Then maybe a list of a few categories of activity, like writing documents, writing code, PIM, utilities, and a terse list of the major actively maintained plugins in each category. With links from these lists to the docs for plugin as collected by plugin_catalog.py, with, finally, a comment that it's worth reading through the list at the top of plugin_catalog.py's output to find other plugins in different levels of functionality for more specific tasks. Even the terse list, above, could be automatically generated if the TODO: parts of plugin_catalog.py can be done, namely: - Design encoding of plugin status in rst docstring - interface (qt/tk/both) - maintained / working / old / broken - maintainer - List of commands provided by plugin (or command pattern, e.g active-path-\*) - List of semantic tags provided by plugin (@bookmark...) (last two are less important / not needed initially) That said, I will look at the documentation you've rescued from the emails, but with an eye to incorporating it into the docstrings of the plugins. That avoids the problem of collaboration in a .leo file, because the collaboration is just in the editing of the plugins .py files. Cheers -Terry > The release notes, in LeoDocs.leo, contain two sets of (identical) docs, > one in the plugins chapter:: > > Users Guide-->Intermediate Topics-->Plugins-->@file plugins.txt-->@rst > html\plugins.html-->Recently added plugins > > and one in the release notes, the top-level clone:: > > Leo 4.11 a1 Release notes-->Plugins > > I would appreciate editorial help for these docs from plugin writers, > especially the "improved" plugins: bookmarks.py, ipython.py, valuespace.py > and viewrendered.py. > > **Please** help me out by: > > 1. Bringing the docs up to date, > > 2. Removing any redundant material, > > 3. Creating up-to-date summaries. > > Given the difficulties of collaborating on .leo files directly, please > announce the corrections *here*. I can then do the merging myself. > > Edward > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
