On Sun, 21 Mar 2010 07:21:31 -0700 (PDT) zpcspm <[email protected]> wrote:
> Terry, now that you are at it, what do you think about delegating one > more task to your code which scans for plugin docstrings: to generate > the default @enabled-plugins? It could also optionally include short > descriptions of each plugin (at the risk of bloating the @enabled > plugins node), so somebody who is deciding which plugins to enable > would not switch attention between the @enabled-plugins node and the > more detailed documentation. I haven't finalized how machine readable info. like status, maintainer, gui dependency etc, should be encoded in a plugin docstring. Probably just rst docinfo elements, :last_update: 20100301 :plugin_status: inital development :gui: qt and tk :maintainer: [email protected] but the field names and content still need to be defined. Anyway, you're proposing that there be a :default: yes field, which is used to generate the @enabled-plugins in .../leo/config/leoSettings.leo? There would also be a :priority: field to sort those few plugins that need to come first to the top of the list. To automate it the code would need to edit leoSettings.leo itself, which is doable. So the defaultness of plugins would be switched on and off in the docstring of the plugin itself. What do you think Edward? Doesn't seem like there's a perfect solution to this. I think the set of plugins which are enabled by default changes quite infrequently. The plus with this system might be making sure all plugins, or at least all stable working plugins, have an entry in @enabled plugins, even if that entry is commented out for most of them (all except the few with ":default: yes"). Sounds like it could be useful. Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
