>
> --[[smcv]]
->> [[!template id=gitbranch author="[[smcv]]" branch=smcv/definetemplate]]
->> [[!tag patch]]
>> OK, here is a branch implementing what I said. It adds the `definetemplate`
>> directive to [[plugins/goodstuff]] as its last commit.
>>
>>>> wants me to, but I think the current approach is simpler,
>>>> so I'll stick with the current approach if it isn't vetoed.
>>>> --[[smcv]]
+
+>>>>> @name: even outside `/templates`, `\[[!templatebody]]` would be
+>>>>> interpreted as "when this page is used as a template, this is what its
+>>>>> contents should be", and be suitable.
+>>>>>
+>>>>> @`%templates`: my surprise wasn't to it not being in `%pagestate`, but
+>>>>> rather that the `scan` function was used for it at all, rather than plain
+>>>>> directive parsing that ignores everything else -- but i agree that it's
+>>>>> the right thing to do in this situation.
+>>>>>
+>>>>> --[[chrysn]]
+
+>>>>>> [[!template id=gitbranch author="[[smcv]]" branch=smcv/ready/templatebody
+ browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/templatebody]]
+>>>>>> [[!tag patch]]
+>>>>>> Branch and directive renamed to `ready/templatebody` as chrysn suggested.
+>>>>>> It's on-by-default now (or will be if that branch is merged).
+>>>>>> Joey, any chance you could review this?
+>>>>>>
+>>>>>> There is one known buglet: `template_syntax.t` asserts that the entire
+>>>>>> file is a valid HTML::Template, whereas it would ideally be doing the
+>>>>>> same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
+
+>>>>>>> Looking over this, I notice it adds a hash containing all scanned
+>>>>>>> files. This seems to me to be potentially a scalability problem on
+>>>>>>> rebuild of a site with many pages. Ikiwiki already keeps a lot
+>>>>>>> of info in memory, and this adds to it, for what is a fairly
+>>>>>>> minor reason. It seems to me there should be a way to avoid this. --[[Joey]]
+
+>>>>>>>> Maybe. Are plugins expected to cope with scanning the same
+>>>>>>>> page more than once? If so, it's just a tradeoff between
+>>>>>>>> "spend more time scanning the template repeatedly" and
+>>>>>>>> "spend more memory on avoiding it", and it would be OK to
+>>>>>>>> omit that, or reduce it to a set of scanned *templates*
+>>>>>>>> (in practice that would mean scanning each template twice
+>>>>>>>> in a rebuild). --s