follow up: optimization partially restored

1 files changed, 8 insertions, 1 deletions

diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn
index 81b8a5c58..9d6915b09 100644
--- a/doc/bugs/template_creation_error.mdwn
+++ b/doc/bugs/template_creation_error.mdwn
@@ -239,7 +239,9 @@ same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
 >>>> during the render phase, namely when a page that is rendered
 >>>> due to dependencies uses a template that no other page being
 >>>> rendered in this pass was using. I've reverted this optimization,
->>>> to fix [[wrong rendering of templatebody]]. --[[smcv]]
+>>>> to fix [[wrong rendering of templatebody]], and applied a more
+>>>> limited version which only optimizes rebuilds (the worst case
+>>>> of this memory consumption). --[[smcv]]
 >>>
 >>> `%scanned` is likely to be no larger than `%rendered`, which
 >>> we already track, and whose useful lifetime does not overlap
@@ -270,6 +272,11 @@ same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
 >>>> decide whether to scan the template page, but would be generally more
 >>>> robust for future plugin writing.
 >>>>
+>>>>> At the moment templatebody really does need to re-scan templates in
+>>>>> the render phase, unfortunately. Not scanning in the render phase
+>>>>> seems to be precisely how [[wrong rendering of templatebody]]
+>>>>> happened. --s
+>>>>
 >>>> **addendum**: if the new phase state is used to create warnings/errors
 >>>> about improper ikiwiki api use of plugins (which is something i'd
 >>>> advocate), that should likewise warn if `add_link` actually adds a link in