error(sprintf(gettext("unsupported page format %s"), $format));
}
- return IkiWiki::htmlize($params{page}, $params{destpage}, $format, $text);
+ return IkiWiki::htmlize($params{page}, $params{destpage}, $format,
+ IkiWiki::preprocess($params{page}, $params{destpage}, $text));
} #}}}
1
>>> [[plugins/write]]. I think you can just inject wrappers about a few ikiwiki
>>> functions, rather than adding hooks. The `inject` function is pretty
>>> insane^Wlow level, but seems to work great. --[[Joey]]
->>
+>>>
>>>> Thanks a lot, it seems to be a nice interface for what I was trying to achieve.
>>>> I may be forced to wait two long weeks before I have a chance to confirm
>>>> this. Stay tuned. --[[intrigeri]]
+>>>>
+>>>>> I've updated the plugin to use `inject`. It is now fully self-contained,
+>>>>> and does not modify the core anymore. --[[intrigeri]]
>>
>> The Discussion pages issue is something I am not sure about yet. But I will
>> probably decide that "slave" pages, being only translations, don't deserve
Err, is this really fixed in 2.21? I can't find it anywhere in 2.32.3
(debian unstable)
+
+-----
+
+I just did a `--dumpsetup` with the current version from the Git repository
+and the default option is
+
+ # use '!'-prefixed preprocessor directives?
+ prefix_directives => 0,
+
+My impression was that this should be enabled by default now. --[[JasonBlevins]]
+
+> As stated in `debian/NEWS`:
+>> For backward compatibility with existing wikis,
+>> refix_directives currently defaults to false. In ikiwiki 3.0,
+>> prefix_directives will default to true [...]
+> --[[intrigeri]]
+
we could use an external plugin..)
* Currently no single plugin supports both modes of operation (directive
and whole source file to page).
+
+ > This is now fixed by the [[ikiwiki/directive/format]] directive for all
+ > whole-source-file plugins, right?
+
* Nothing seems to support
[[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
inside source files. Doing this probably means post-processing the
One approach that's also been requested for eg,
[[plugins/contrib/mediawiki]] is to allow controlling which linkification
types a page type can have on it.
+
+ > The previous two points seem to be related. One thought: instead of
+ > getting the source from the `content` parameter, the plugin could
+ > re-load the page source. That would stop directives/links from
+ > being processed in the source. As noted above, comments
+ > could then be parsed for directives/links later.
+ >
+ > Would it be worth adding a `nodirectives` option when registering
+ > an htmlize hook that switches off directive and link processing before
+ > generating the html for a page?
+
* The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`.
This is trivially fixable now by passing the keepextension option when
registering the htmlize hooks, though.
extensions. The workaround is to use a directive on a wiki page, pulling
in the Makefile.
+ > I wonder how hard it would be to make a patch whereby a file with
+ > no `.` in the name, and a name that matches a filetype, and where
+ > that filetype was registered `keepextension`, then the file is just
+ > chosen as the appropriate type. This would allow `Makefile` to
+ > work.
+
+like this:
+
+ diff --git a/IkiWiki.pm b/IkiWiki.pm
+ index 8d728c9..1bd46a9 100644
+ --- a/IkiWiki.pm
+ +++ b/IkiWiki.pm
+ @@ -618,6 +618,8 @@ sub pagetype ($) { #{{{
+
+ if ($page =~ /\.([^.]+)$/) {
+ return $1 if exists $hooks{htmlize}{$1};
+ + } elsif ($hooks{htmlize}{$page}{keepextension}) {
+ + return $page;
+ }
+ return;
+ } #}}}
+
## format directive
Rather than making syntax highlight plugins have to provide a preprocessor