doc/todo/Add_a_plugin_to_list_available_pre-processor_commands.mdwn

   1 I've found myself wanting to know which [[plugins]] are switched on so I know which pre-processor commands I can use.  The attached [[patch]] adds a new plugin that generates the list of available plugins. -- [[Will]]
   2
   3 > Good idea, I do see a few problems:
   4 >
   5 > - preprocessor directives do not necessarily have the same name as the
   6 >   plugin that contains them (for example, the graphviz plugin adds a graph
   7 >   directive). Won't keys `%{IkiWiki::hooks{preprocess}}` work?
   8
   9 >>> Er, yeah - that's a much better solution. :) -- and done
  10
  11 > - "listplugins" is a bit misnamed since it only does preprocessor directives.
  12
  13 >>> Yes.  Initially this was going to list all enabled plugins.  Then when searching
  14 >>> for enabled plugins I changed my mind and decided that a list of pre-processor
  15 >>> directives was more useful.  I'll fix that too. -- changed to `listpreprocessors`
  16
  17 > - comment was copied from version plugin and still mentions version :-)
  18
  19 >>> :-) -- fixed
  20
  21 > - Seems like [[ikiwiki/formatting]] could benefit from including the
  22 >   list.. however, just a list of preprocessor directive names is not
  23 >   the most user-friendly thing that could be put on that page. It would
  24 >   be nice if there were also a short description and maybe an example of
  25 >   use. Seems like the place to include that info would be in the call
  26 >   to `hook()`.
  27 >   (Maybe adding that is more involved than you want to go though..)
  28 >
  29 > --[[Joey]]
  30
  31 >> Adding a whole new hook for a usage example is more effort than I
  32 >> wanted to go to.  I was thinking of either:
  33
  34 >>> Just to clarify, I meant adding new parameters to the same hook call
  35 >>> that registers the plugin. --[[Joey]]
  36
  37 >>    - Adding a configuration for a wiki directory.  If a matching page is in the
  38 >>      specified wiki directory then the plugin name gets turned into a link to that
  39 >>      page
  40 >>    - Adding configuration for an external URL.  Each plugin name is added as
  41 >>       a link to the plugin name appended to the URL.
  42
  43 >>The first option is easier to navigate and wouldn't produce broken links,
  44 >>but requires all the plugin documentation to be local.  The second option
  45 >>can link back to the main IkiWiki site, but if you have any non-standard
  46 >>plugins then you'll get broken links.
  47 >>
  48 >>Hrm.  After listing all of that, maybe your idea with the hooks is the better
  49 >>solution.  I'll think about it some more. -- [[Will]]
  50
  51 >>> I've also run into this problem with the websetup plugin, and
  52 >>> considered those ideas too. I don't like the external url, because
  53 >>> ikiwiki.info may be out of sync with the version of ikiwiki being used.
  54 >>> (Or maybe it's gone! :-) The first idea is fine, except for the bloat
  55 >>> issue. If turning on listpreprocessors and/or websetup means adding
  56 >>> hundreds of pages (and of kilobytes) to your wiki, that could be an
  57 >>> incentive to not turn them on..
  58 >>>
  59 >>> Hmm.. maybe the thing to do is to use _internal pages for the plugins;
  60 >>> then the individual pages would not be rendered, and your inlines would
  61 >>> still work. Although I don't know how websetup would use it then, and
  62 >>> also they would have to be non-internal for ikiwiki's own docwiki. Hmm.
  63 >>> Maybe these are two different things; one is a set of pages describing
  64 >>> preprocessor directives, and the second a set of pages describing
  65 >>> plugins. They're so closely related though it seems a shame to keep
  66 >>> them separate..
  67 >>> --[[Joey]]
  68
  69 >>> I started implementing the hook based solution, and decided I didn't like
  70 >>> it because there was no nice way to rebuild pages when the preprocessor
  71 >>> descriptions changed.  So instead I assumed that the the [[plugins]] pages
  72 >>> would be moved into the underlay directory.  This plugin then uses an
  73 >>> `inline` directive to include those pages.  You can use the `inline`
  74 >>> parameter to decide if you want to include all the descriptions or
  75 >>> just the titles.  There is also an option to auto-create default/blank
  76 >>> description pages if they are missing (from a template).  As preprocessor
  77 >>> commands don't list unless they have a description page, auto-creation
  78 >>> is enabled by default.
  79 >>>
  80 >>>  There are three new templates that are needed.  These are for:
  81 >>>
  82 >>>  - The auto-created description pages are generated from `preprocessor-description.tmpl`.
  83 >>>  - When only pre-processor names are listed, the `listpreprocessors-listonly.tmpl` template is used.
  84 >>>  - When pre-processor descriptions are included inline, the `listpreprocessors-inline.tmpl` template is used.
  85 >>>
  86 >>> -- [[Will]]
  87
  88 >>>> Just a quick note: pages are only created for pre-processor commands
  89 >>>> that exist when the `refresh` hook is called.  This is before the [[shortcuts]] are
  90 >>>> processed.  However, the list of available pre-processor commands will include
  91 >>>> shortcuts if they have description pages (the list is generated later, after the
  92 >>>> shortcuts have been added).  While this was unplanned, it seems a reasonable
  93 >>>> tradeoff between including all the large number of shortcuts and including none. -- [[Will]]
  94
  95 >>>>>> I think that using an inline is elegant! However, I don't understand
  96 >>>>>> why it has to create stub description pages? I doubt that, if a
  97 >>>>>> directive is missing a page, the stub will be filled out in many
  98 >>>>>> wikis. And it adds a lot of complexity, particularly committing a
  99 >>>>>> bunch of generated pages to revision control when the user just
 100 >>>>>> wants a plugin list seems undesirable.
 101 >>>>>>
 102 >>>>>> Seems to me it could use the inline for pages that exist, and append
 103 >>>>>> to the bottom a generated text for anything that is currently missing.
 104 >>>>>> The generated text could even have a page creation link in it if
 105 >>>>>> you wanted.
 106 >>>>>> --[[Joey]]
 107
 108 >>>>>>> I kinda agree about the page generation.  I don't like mixing an
 109 >>>>>>> inlined and a list though.  Besides which, that ends
 110 >>>>>>> up keeping much of complexity of the page generation because
 111 >>>>>>> the code still has to detect which pages are missing.  I've added
 112 >>>>>>> a patch that uses a list of wikilinks instead.  This way available
 113 >>>>>>> pages get linked correctly, and missing pages get normal creation
 114 >>>>>>> links.  The old patch is still here if you decide you prefer that. -- [[Will]]
 115
 116 >>>>>>>> Can you explain the full/early list (why track both?) and generated parameter?
 117
 118 >>>>>>>>> If you add in all the shortcuts you get quite a long list.  My original idea
 119 >>>>>>>>> was to just track the plugin commands.  This is the early list.  But then
 120 >>>>>>>>> I thought that it might be nice for someone looking at wiki source and
 121 >>>>>>>>> seeing a shortcut to know where it came from.  So I decided to make
 122 >>>>>>>>> displaying the full list an option, with the original concept as the default.
 123
 124 >>>>>>>>> Another option here might be to generate the full list every time, but give
 125 >>>>>>>>> generated pre-processor commands (e.g. shortcuts) a different css class.
 126 >>>>>>>>> I'm not sure that is better than what I have though.
 127
 128 >>>>>>>>> I keep track of both in the page state because if a command moves from
 129 >>>>>>>>> a shortcut to the early list (or vice versa) it changes what should be
 130 >>>>>>>>> displayed in the default use of the plugin.  I thought about tracking just what
 131 >>>>>>>>> was actually used on the page, but I don't know in the needsbuild hook whether the `generated`
 132 >>>>>>>>> parameter has been supplied (or maybe the plugin is used twice on the page -
 133 >>>>>>>>> once in each form).  It was just easier to track both.
 134
 135 >>>>>>>> Only code change I'd suggest is using `htmllink` rather than
 136 >>>>>>>> generating a wikilink.
 137
 138 >>>>>>>>> Yeah - that would make sense.  done. -- [[Will]]
 139
 140 Patch is applied (along with some changes..). [[done]] (But, see
 141 [[directive_docs]].