]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/commitdiff
refreshing three pending patches
authorchrysn <chrysn@fsfe.org>
Sun, 29 Jun 2014 18:06:26 +0000 (20:06 +0200)
committerchrysn <chrysn@fsfe.org>
Sun, 29 Jun 2014 18:06:26 +0000 (20:06 +0200)
doc/bugs/linkmap_displays_underscore_escapes.mdwn
doc/bugs/pythonproxy-utf8_again.mdwn
doc/bugs/svg_and_pdf_conversion_fails.mdwn

index 66bffc15954ffbbb5d9f7c5d3540cdb1a4dcd951..62cfb3471fe64d5136902c233f62090d2324e943 100644 (file)
@@ -19,3 +19,5 @@ the output will look much better (at least in my wikis) with the "[[bugs/pagetit
 
 the patch is stored in [[the patch.pl]] as created by git-format-patch, and can
 be pulled from the abovementioned branch.
+
+> update 2014-06-29: branch still merges cleanly and works. --[[chrysn]]
index 96b0600036d33346afb09081df2a94eff0e780c2..14d5cb98e6e51ec2dd6baaddbeef3e3e5dd49aa1 100644 (file)
@@ -14,3 +14,23 @@ version, but i'm pretty sure it was already broken after the abovementioned
 patch.
 
 -- [[chrysn]]
+
+> update 2014-06-29: the problem persists, but i found it is not trivial to
+> reproduce. to demonstrate, use this test plugin:
+>
+>    #!/usr/bin/env python
+>    # -*- coding: utf-8 -*-
+>    
+>    from proxy import IkiWikiProcedureProxy
+>    
+>    def preprocess(self, proxy, *args):
+>        return repr(self.rpc('pagetype', 'schön'))
+>    
+>    proxy = IkiWikiProcedureProxy(__name__)
+>    proxy.hook('preprocess', preprocess, id='testdirective')
+>    proxy.run()
+>
+> note that when the 'schön' is stored in a variable, the exception changes --
+> it seems to me that the issue is related to the way exceptions are encoded.
+>
+> the suggested patch still applies and solves the issue. --[[chrysn]]
index 41637c51d93c735a189365339f9ddb6cc7960f19..da241b4bcc1948ee15bb88513a5ad699039e01ef 100644 (file)
@@ -20,3 +20,8 @@ that needs special care or breaks something i don't use; this way, my patches
 should be safe for inclusion.
 
 --[[chrysn]]
+
+> update 2014-06-29: the patch still applies and fixes the issue. in the
+> meantime, i noticed that the desired effect doesn't happen when no explicit
+> size is set. as scalable graphics don't necessarily have a natural size
+> anyway, i don't consider that a showstopper. --[[chrysn]]