]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/inline_raw_files.mdwn
proposed plugin
[git.ikiwiki.info.git] / doc / todo / inline_raw_files.mdwn
index ef7fcb12c024f1c280e6220ec1555079e86300bc..52a4be7265667b111dd89229e3dfd49f02f58af0 100644 (file)
@@ -9,7 +9,7 @@ Also raise an error in `IkiWiki::pagetype($file)` if `$file` is blank, which avo
 
 I'm using the new code in my [blog][].
 
-[blog]: http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/yacc2dot/
+[blog]: http://blog.tremily.us/posts/yacc2dot/
 
 usage
 =====
@@ -88,3 +88,28 @@ which seems likely.
 Or, another way to do it would be to use the templates plugin, and make
 a template there that puts an inline directive inside pre tags.
  --[[Joey]] [[!tag reviewed]]
+
+----
+
+If `pagetype()` cannot fail, then I suppose that check has to go ;).
+
+I was under the impression that [[plugins/highlight]] didn't support
+inlining code.  It looks like it supports highlighing stand-alone
+files or embedded code.  Perhaps I should extend it to support inlined
+code instead of pushing this patch?
+
+> If you configure highlight to support standalone files, then you can
+> inline the resulting pages and get nicely highlighted source code
+> inlined into the page. --[[Joey]]
+
+The `raw.tmpl` included in the patch *does* include the inlined
+content inside `pre` tags.  The problem is that the current inline
+code insists on running `htmlize()` on the content before inserting it
+in the template.  The heart of my patch is an altered
+`get_inline_content()` that makes the `htmlize()` call dependent on a
+`$read_raw` flag.  If the flag is set, the raw (non-htmlized) content
+is used instead.
+
+I just rebased my patches against the current Ikiwiki trunk (no major
+changes) to make them easier to review.
+ --[[wtk]]