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

Good idea, I do see a few problems:

• preprocessor directives do not necessarily have the same name as the plugin that contains them (for example, the graphviz plugin adds a graph directive). Won't keys %{IkiWiki::hooks{preprocess}} work?

Er, yeah - that's a much better solution. -- and done

• "listplugins" is a bit misnamed since it only does preprocessor directives.

Yes. Initially this was going to list all enabled plugins. Then when searching for enabled plugins I changed my mind and decided that a list of pre-processor directives was more useful. I'll fix that too. -- changed to listpreprocessors

• comment was copied from version plugin and still mentions version

-- fixed

• Seems like formatting could benefit from including the list.. however, just a list of preprocessor directive names is not the most user-friendly thing that could be put on that page. It would be nice if there were also a short description and maybe an example of use. Seems like the place to include that info would be in the call to hook(). (Maybe adding that is more involved than you want to go though..)

--Joey

Adding a whole new hook for a usage example is more effort than I wanted to go to. I was thinking of either:

Just to clarify, I meant adding new parameters to the same hook call that registers the plugin. --Joey

• Adding a configuration for a wiki directory. If a matching page is in the specified wiki directory then the plugin name gets turned into a link to that page
• Adding configuration for an external URL. Each plugin name is added as a link to the plugin name appended to the URL.

The first option is easier to navigate and wouldn't produce broken links, but requires all the plugin documentation to be local. The second option can link back to the main IkiWiki site, but if you have any non-standard plugins then you'll get broken links.

Hrm. After listing all of that, maybe your idea with the hooks is the better solution. I'll think about it some more. -- Will

I've also run into this problem with the websetup plugin, and considered those ideas too. I don't like the external url, because ikiwiki.info may be out of sync with the version of ikiwiki being used. (Or maybe it's gone! The first idea is fine, except for the bloat issue. If turning on listpreprocessors and/or websetup means adding hundreds of pages (and of kilobytes) to your wiki, that could be an incentive to not turn them on..

Hmm.. maybe the thing to do is to use _internal pages for the plugins; then the individual pages would not be rendered, and your inlines would still work. Although I don't know how websetup would use it then, and also they would have to be non-internal for ikiwiki's own docwiki. Hmm. Maybe these are two different things; one is a set of pages describing preprocessor directives, and the second a set of pages describing plugins. They're so closely related though it seems a shame to keep them separate.. --Joey

I started implementing the hook based solution, and decided I didn't like it because there was no nice way to rebuild pages when the preprocessor descriptions changed. So instead I assumed that the the plugins pages would be moved into the underlay directory. This plugin then uses an inline directive to include those pages. You can use the inline parameter to decide if you want to include all the descriptions or just the titles. There is also an option to auto-create default/blank description pages if they are missing (from a template). As preprocessor commands don't list unless they have a description page, auto-creation is enabled by default.

There are three new templates that are needed. These are for:

• The auto-created description pages are generated from preprocessor-description.tmpl.
• When only pre-processor names are listed, the listpreprocessors-listonly.tmpl template is used.
• When pre-processor descriptions are included inline, the listpreprocessors-inline.tmpl template is used.

-- Will

Just a quick note: pages are only created for pre-processor commands that exist when the refresh hook is called. This is before the shortcuts are processed. However, the list of available pre-processor commands will include shortcuts if they have description pages (the list is generated later, after the shortcuts have been added). While this was unplanned, it seems a reasonable tradeoff between including all the large number of shortcuts and including none. -- Will

I think that using an inline is elegant! However, I don't understand why it has to create stub description pages? I doubt that, if a directive is missing a page, the stub will be filled out in many wikis. And it adds a lot of complexity, particularly committing a bunch of generated pages to revision control when the user just wants a plugin list seems undesirable.

Seems to me it could use the inline for pages that exist, and append to the bottom a generated text for anything that is currently missing. The generated text could even have a page creation link in it if you wanted. --Joey

I kinda agree about the page generation. I don't like mixing an inlined and a list though. Besides which, that ends up keeping much of complexity of the page generation because the code still has to detect which pages are missing. I've added a patch that uses a list of wikilinks instead. This way available pages get linked correctly, and missing pages get normal creation links. The old patch is still here if you decide you prefer that. -- Will

Can you explain the full/early list (why track both?) and generated parameter?

If you add in all the shortcuts you get quite a long list. My original idea was to just track the plugin commands. This is the early list. But then I thought that it might be nice for someone looking at wiki source and seeing a shortcut to know where it came from. So I decided to make displaying the full list an option, with the original concept as the default.

Another option here might be to generate the full list every time, but give generated pre-processor commands (e.g. shortcuts) a different css class. I'm not sure that is better than what I have though.

I keep track of both in the page state because if a command moves from a shortcut to the early list (or vice versa) it changes what should be displayed in the default use of the plugin. I thought about tracking just what was actually used on the page, but I don't know in the needsbuild hook whether the generated parameter has been supplied (or maybe the plugin is used twice on the page - once in each form). It was just easier to track both.

Only code change I'd suggest is using htmllink rather than generating a wikilink.

Yeah - that would make sense. done. -- Will

Patch is applied (along with some changes..). done (But, see directive docs.