bug responses

(Yes, I'm still alive)

diff --git a/doc/bugs/htmlscrubber_still_scrubbing_HTML_from_mdwn_pages.mdwn b/doc/bugs/htmlscrubber_still_scrubbing_HTML_from_mdwn_pages.mdwn
index 56b33d4573a42fce6bf85ebb70c1611e88e8fb39..8e79cdd49194ac7eddb8664b4ce2f3e3b9c1fd28 100644 (file)
--- a/doc/bugs/htmlscrubber_still_scrubbing_HTML_from_mdwn_pages.mdwn
+++ b/doc/bugs/htmlscrubber_still_scrubbing_HTML_from_mdwn_pages.mdwn
@@ -3,3 +3,19 @@ Though [[htmlscrubber|plugins/htmlscrubber]] is disabled on the Branchable site
 <http://geekout.org.uk/actual_route/>
 
 I assumed one can mix and match HTML in markdown?
+
+> I checked, htmlscrubber is really disabled. So it's not scrubbing
+> anything. Really.
+> 
+> What is going on is you have found a bug in markdown. If you feed the
+> file into markdown directly you will see a bunch of weird hashes
+> like 67255d9b2a988139c95269498399f10a in place of your html,
+> so this is like [[!debbug 380212]] but that was with the other version of
+> markdown; I have not seen the current version behave this way before.
+> 
+> One workaround is to wrap the html in a span tag. Another is to switch
+> the page from .mdwn to .html and enable the html plugin. I guess I'd pick
+> the first if I were you.
+> 
+> I've filed [[!debbug 647128]] about this. Since it's not really an ikiwiki
+> bug, I'll close this one. [[done]] --[[Joey]]

diff --git a/doc/bugs/several_entries_in_docs__47__bugs_contain_colons_in_the_filename.mdwn b/doc/bugs/several_entries_in_docs__47__bugs_contain_colons_in_the_filename.mdwn
index c7cf8e320a52e51f642fae98db82b61bb3d05ad3..03f4787780f5abb2b3e2587826e16f27a1a8b451 100644 (file)
--- a/doc/bugs/several_entries_in_docs__47__bugs_contain_colons_in_the_filename.mdwn
+++ b/doc/bugs/several_entries_in_docs__47__bugs_contain_colons_in_the_filename.mdwn
@@ -1 +1,9 @@
 I just tried to clone the git repo onto a windows machine to test things out a bit and it turns out i cannot even successfully checkout the code because of those colons. Would a patch changing those to underscores be accepted?
+
+> Well, this is a difficult thing. Ikiwiki has a configuration setting to
+> prevent it writing filenames with colons, but for backwards compatability
+> that is not enabled by default. Also nothing would stop people from
+> making commits that added filenames with colons even if it were disabled
+> in ikiwiki. I don't know that trying to work around obscure limitations
+> in OSs that I've never heard of ikiwiki being used on is worth the bother
+> TBH, but have not really made up my mind. --[[Joey]]

diff --git a/doc/bugs/wiki_rebuild_should_throw_errors_if_the_configured_underlaydir_or_templatedir_don__39__t_exist.mdwn b/doc/bugs/wiki_rebuild_should_throw_errors_if_the_configured_underlaydir_or_templatedir_don__39__t_exist.mdwn
index 8da9f4f6b3e4cdead7d964bf355d5577cd411391..2b096b2a67d2776b0abce0eb626ce92136fecdec 100644 (file)
--- a/doc/bugs/wiki_rebuild_should_throw_errors_if_the_configured_underlaydir_or_templatedir_don__39__t_exist.mdwn
+++ b/doc/bugs/wiki_rebuild_should_throw_errors_if_the_configured_underlaydir_or_templatedir_don__39__t_exist.mdwn
@@ -1 +1,13 @@
 I originally set up ikiwiki by using the debian package, but had some odd issues, so i figured i'd try installing from git. To do that i uninstalled the debian package and then did the Makefile dance from the git dir. In that process the original dirs configured in templatedir underlaydir in my wiki were deleted; HOWEVER when rebuilding the script just went ahead and did not even note the lack of those dirs. It would be nice if it threw errors if the dirs were configured, but non-existant.
+
+> Hmm. This behavior was explicitly coded into ikiwiki for underlay dirs:
+> [commit](http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=cb4b99929757f970d5ae697f0d09514ad624ed46).
+> Pity I didn't say why, but presumably there are cases 
+> where one of the underlaydirs is expected to be missing, or where
+> this robustness of not crashing is needed.
+> 
+> The situation with missing templatedirs is more clear: When
+> it's looking for a given template file it just tries to open it in each
+> directory in turn, and uses the first file found; checking that a
+> directory exists would be extra work and there's a nice error message if 
+> a template cannot be found. --[[Joey]]