]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
clarifications. and indent one of joey's oneliner responses.
[git.ikiwiki.info.git] / doc / todo / Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 4468ce1e997526d0b9e3eb33df0c55bf77f3779d..084f033042f04e7636752d5a13d0e6696c2380e3 100644 (file)
@@ -77,6 +77,17 @@ but disruptive since all .rst depend on it). Well, the customizations have
 to be picked and chosen from this, but at least the global python file can
 be very convenient.
 
 to be picked and chosen from this, but at least the global python file can
 be very convenient.
 
+> Did you consider just including the global rst header text into an item
+> in the setup file? --[[Joey]] 
+>
+>> Then `rst_header` would not be much different from the python script
+>> `rst_customize`. rst_header is as safe as other files (though disruptive
+>> as noted), so it should/could be a editable file in the Wiki. A Python
+>> script of course can not be. There is nothing you can do in the
+>> rst_header (that you sensibly would do, I think) that couldn't be done in
+>> the Python script. `rst_header` has very limited use, but it is another
+>> possibility, mainly for the user-editable aspect. --[[ulrik]]
+
 Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/)
 
 [rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize
 Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/)
 
 [rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize
@@ -141,6 +152,20 @@ picture before it.
 >> use more rst-like syntax (and documents degrades better outside the wiki as
 >> noted).
 >>
 >> use more rst-like syntax (and documents degrades better outside the wiki as
 >> noted).
 >>
+>>> Unsure about the degredation argument. It will work some of
+>>> the time, but ikiwiki's [[ikiwiki/subpage/linkingrules]]
+>>> are sufficiently different from normal html relative link
+>>> rules that it often won't work. --[[Joey]]
+>>>
+>>>> With degradation I mean that if you take a file out of the wiki; the
+>>>> links degrade to stylized text. If using default role, they degrade to
+>>>> :title: which renders italicized text (which I find is exactly
+>>>> appropriate). There is no way for them to degrade into links, except of
+>>>> course if you reimplement the :wiki: role. You can also respecify
+>>>> either the default role (the `wikilink` syntax) or the :wiki: role (the
+>>>> :wiki:`wikilink` syntax) to any other markup, for example None.
+>>>> --[[ulrik]]
+>> 
 >> The named link syntax (just like the :wiki: role) are inspired from trac
 >> and a good fit, but only if the wiki is committed to using only rst,
 >> which I don't think is the case.
 >> The named link syntax (just like the :wiki: role) are inspired from trac
 >> and a good fit, but only if the wiki is committed to using only rst,
 >> which I don't think is the case.
@@ -165,9 +190,11 @@ picture before it.
 >> other phases? rst must be before any preprocess hook to avoid seeing any
 >> HTML.
 >>
 >> other phases? rst must be before any preprocess hook to avoid seeing any
 >> HTML.
 >>
->> With the presented changes, I already have a working RestructuredText
->> wiki, but I'm admitting that using .. raw:: html around all directives is
->> very ugly (I use few directives: inline, toggle, meta, tag, map)
+>>> One of my long term goals is to refactor all the code in ikiwiki
+>>> that manually runs the various stages of the render pipeline,
+>>> into one centralized place. Once that's done, that place can get
+>>> smart about what order to run the stages, and use a different
+>>> order for rst. --[[Joey]]
 >>
 >> If I'm thinking right, processing to HTML already in filter means any
 >> processing in scan can be reused directly (or skipped if it's legal to
 >>
 >> If I'm thinking right, processing to HTML already in filter means any
 >> processing in scan can be reused directly (or skipped if it's legal to
@@ -175,6 +202,7 @@ picture before it.
 >>
 >> -- [[ulrik]] 
 
 >>
 >> -- [[ulrik]] 
 
+>>> Seems it could be, yes. --[[Joey]]
 
 ### Implementation ###
 
 
 ### Implementation ###
 
@@ -215,10 +243,16 @@ Perl I've ever written!_)
 >> Well, no idea how that would be expressed, but I mean, replace the indent
 >> directly in $handle's return value.
 >>
 >> Well, no idea how that would be expressed, but I mean, replace the indent
 >> directly in $handle's return value.
 >>
+>>> Yes, in effect just `indent($1, handle->($2,$,4))` --[[Joey]] 
+>>
 >> The indent-catching regex is wrong in the way you mention, it has been
 >> nagigng my mind a bit as well; I think matching start of line + spaces
 >> and tabs is the only thing we want.
 >> -- [[ulrik]]
 >> The indent-catching regex is wrong in the way you mention, it has been
 >> nagigng my mind a bit as well; I think matching start of line + spaces
 >> and tabs is the only thing we want.
 >> -- [[ulrik]]
+>> 
+>>> Well, seems you want to match the indent at the start of the line containing
+>>> the directive, even if the directive does not start the line. That would
+>>> be quite hard to make a regexp do, though. --[[Joey]]
 
 [ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent
 
 
 [ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent