From 14607a10f92c8859fc6c4b28c59b228c131f9c87 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 30 Oct 2011 12:48:34 -0400 Subject: [PATCH] bug responses (Yes, I'm still alive) --- ...ber_still_scrubbing_HTML_from_mdwn_pages.mdwn | 16 ++++++++++++++++ ..._47__bugs_contain_colons_in_the_filename.mdwn | 8 ++++++++ ...erlaydir_or_templatedir_don__39__t_exist.mdwn | 12 ++++++++++++ 3 files changed, 36 insertions(+) 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 56b33d457..8e79cdd49 100644 --- 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 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 c7cf8e320..03f478778 100644 --- 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 8da9f4f6b..2b096b2a6 100644 --- 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]] -- 2.26.2