lib/tasks/index.rake: handle nested AsciiDoc includes

When indexing contents in the Documentation tree, our Rakefile
preprocesses each blob by resolving its includes before handing it off
to AsciiDoc.

This preprocessing is implemented by the `~expand_content` method,
which performs a string substitution on the pattern

    /include::(\S+)\.txt\[\]/

, where the block given to `#gsub` yields the content of the file in the
first match group. When the file isn't pre-generated, we ask for its
content, recursively call `#expand_content`, and then return the result.

This should handle nested includes, but doesn't. That's because when we
make the recursive call to `#expand_content` we discard the result,
instead returning `new_content` (which is the non-expanded version of
the file we looked up in the first place).

Resolve this by storing off the result of calling `#expand_content`
before returning it.

This broke in eb8f3ca4 (index: make return of new_content clear in
expand_content(), 2022-10-05), the result of calling `#expand_content`
used to be the terminal expression in that method (and thus returned to
the caller).

Signed-off-by: Taylor Blau <me@ttaylorr.com>

1 files changed, 2 insertions, 1 deletions

diff --git a/lib/tasks/index.rake b/lib/tasks/index.rake
index 85ca66bf..e669e033 100644
--- a/lib/tasks/index.rake
+++ b/lib/tasks/index.rake
@@ -150,7 +150,8 @@ def expand_content(content, path, get_f_content, generated)
     else
       new_content = get_f_content.call(new_fname)
       if new_content
-        expand_content(new_content.force_encoding("UTF-8"), new_fname, get_f_content, generated)
+        new_content = expand_content(new_content.force_encoding("UTF-8"),
+                                     new_fname, get_f_content, generated)
       else
         puts "#{new_fname} could not be resolved for expansion"
       end