Merge branch 'master' into po

Conflicts:
	debian/changelog

13 files changed, 326 insertions, 47 deletions

diff --git a/doc/bugs/Insecure_dependency_in_mkdir.mdwn b/doc/bugs/Insecure_dependency_in_mkdir.mdwn
index 67b30e687..28304b3d3 100644
--- a/doc/bugs/Insecure_dependency_in_mkdir.mdwn
+++ b/doc/bugs/Insecure_dependency_in_mkdir.mdwn
@@ -82,3 +82,48 @@ I can't see any related entries. Any ideas?
 
 >>> Ubuntu Gutsy also has Perl 5.8.8-7, so probably it has the bug too.
 >>> --[[Paweł|ptecza]]
+
+>>>> I just got it while building my latest version of git.ikiwiki.info + my stuff.
+>>>> Only thing different in my version in IkiWiki.pm is that I moved a </a> over
+>>>> a word (for createlink), and disabled the lowercasing of created pages. Running
+>>>> Lenny's Perl. --[[simonraven]]
+
+>>>> Simon, I'm not clear what version of ikiwiki you're using.
+>>>> Since version 2.40, taint checking has been disabled by
+>>>> default due to the underlying perl bug. Unless you
+>>>> build ikiwiki with NOTAINT=0. --[[Joey]] 
+
+>>>> Hi, nope not doing this. Um, sorry, v. 3.13. I've no idea why it suddenly started doing this.
+>>>> It wasn't before. I've been messing around IkiWiki.pm to see if I can set
+>>>> a umask for `mkdir`.
+
+line 775 and down:
++			        umask ($config{umask} || 0022);
+
+>>>> I figured it *might* be the `umask`, but I'll see in a few when / if it gets past that in the build. No; I keep getting garbage during the brokenlinks test
+
+<pre>
+t/basewiki_brokenlinks.....Insecure dependency in mkdir while running with -T switch at IkiWiki.pm line 776.
+
+#   Failed test at t/basewiki_brokenlinks.t line 11.
+
+#   Failed test at t/basewiki_brokenlinks.t line 19.
+
+
+broken links found
+&lt;li>shortcut from &lt;a href="./shortcuts/">shortcuts&lt;/a>&lt;/li>&lt;/ul>
+
+
+
+#   Failed test at t/basewiki_brokenlinks.t line 25.
+Insecure dependency in mkdir while running with -T switch at IkiWiki.pm line 776.
+
+#   Failed test at t/basewiki_brokenlinks.t line 11.
+
+#   Failed test at t/basewiki_brokenlinks.t line 25.
+# Looks like you failed 5 tests of 12.
+dubious
+        Test returned status 5 (wstat 1280, 0x500)
+</pre>
+
+>>>> I get this over and over... I haven't touched that AFAICT, at all. --[[simonraven]]
diff --git a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn
new file mode 100644
index 000000000..bd895127a
--- /dev/null
+++ b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn
@@ -0,0 +1,3 @@
+If I have a &lt;--#include virtual="foo" --&gt; in some file, it gets stripped, even though other HTML comments don't get stripped. I imagine it's some plugin doing it, or IkiWiki itself, or an IkiWiki dependency, but I haven't found where this is happening. I'm trying to implement a workaround for my sidebars forcing a rebuild of the wiki every day - I use the calendar plugin - when the day changes, by using SSI.
+
+> It is probably the [[plugins/htmlscrubber]] plugin. -- [[Jon]]
diff --git a/doc/bugs/Titles_are_lower-cased_when_creating_a_page.mdwn b/doc/bugs/Titles_are_lower-cased_when_creating_a_page.mdwn
index f2c60309b..059415819 100644
--- a/doc/bugs/Titles_are_lower-cased_when_creating_a_page.mdwn
+++ b/doc/bugs/Titles_are_lower-cased_when_creating_a_page.mdwn
@@ -4,17 +4,19 @@ If I click on "Czars in Russia", I'd like Ikiwiki to create "Czars\_in\_Russia.m
 
 > There's a simple patch that can do this:
 
-> --- a/IkiWiki.pm
-> +++ b/IkiWiki.pm
-> @@ -584,7 +584,7 @@ sub htmllink ($$$;@) {
->  			return "<span class=\"createlink\"><a href=\"".
->  				cgiurl(
->  					do => "create",
-> -					page => pagetitle(lc($link), 1),
-> +					page => pagetitle($link, 1),
->  					from => $lpage
->  				).
->  				"\">?</a>$linktext</span>"
+<pre>
+-- a/IkiWiki.pm
++++ b/IkiWiki.pm
+@@ -584,7 +584,7 @@ sub htmllink ($$$;@) {
+ 			return "&lt;span class=\"createlink\">&lt;a href=\"".
+ 				cgiurl(
+ 					do => "create",
+-					page => pagetitle(lc($link), 1),
++					page => pagetitle($link, 1),
+ 					from => $lpage
+ 				).
+ 				"\">?&lt;/a>$linktext&lt;/span>"
+</pre>
 
 > This is fine if you don't mind mixed or randomly cased filenames getting
 > created. Otoh, if the link happened to start a sentence and so had its
diff --git a/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn b/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn
new file mode 100644
index 000000000..415e6af91
--- /dev/null
+++ b/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn
@@ -0,0 +1,43 @@
+I was just hovering over the '...' next to the backlinks on a page on
+<http://ikiwiki.info/>. In terms of the size of my browser window, this was
+towards the bottom-right of the screen.
+
+When I hovered over the '...', the additional backlinks float appeared. This
+caused the page length to grow down, meaning a horizontal scrollbar was added
+to the page. This meant the text reflowed, and the '...' moved outside of my
+mouse pointer region.
+
+This caused an infinite loop of box appears... text moves, box disappears...
+box re-appears.. which was not very visually pleasant.
+
+In general I think that the onhover float is a bit of bad UI. Even a truncated
+list of backlinks looks cluttered due to there being no delimiters. I moved to
+having an always-complete list of backlinks and having them as LI elements
+inside a UL to make it look neater, although I appreciate that would make some
+pages very long indeed.
+
+How about doing something a little like [[plugins/toggle]] for the excess
+items instead?
+
+-- [[Jon]]
+
+----
+
+An additional, related issue: if the box expands beyond the bottom of the
+page, you might move your mouse pointer to the scrollbar in order to move
+further down the list, but of course then you are outside the hover region.
+
+-- [[Jon]]
+
+> I agree, browser handling of this CSS is often not good.
+> 
+> A toggle would be the perfect UI, but the heaviness of needing
+> to include 30 lines of javascript to do it, plus then it only working
+> with javascript enabled, is also not optimal.
+> 
+> Another idea would be to make the "..." a link to the ikiwiki cgi. 
+> The cgi could then have a mode that displays all the backlinks of a page
+> in a list.
+> 
+> Yet another idea: Find some more refined CSS for handling a variable
+> size popup.. --[[Joey]] 
diff --git a/doc/bugs/edit_preview_resolves_links_differently_from_commit.mdwn b/doc/bugs/edit_preview_resolves_links_differently_from_commit.mdwn
new file mode 100644
index 000000000..320eca626
--- /dev/null
+++ b/doc/bugs/edit_preview_resolves_links_differently_from_commit.mdwn
@@ -0,0 +1,23 @@
+I'm editing /posts/foo. If I create a link to a subpage (in my case,
+"discussion"), and hit preview, it gets resolved to /discussion, not
+/posts/foo/discussion. If I hit commit, the latter happens. This seems like
+a bug. --liw
+
+> That would be a bug, but I cannot reproduce it. For example, I edited
+> <http://kitenet.net/~joey/blog/entry/wikis_out_of_disk/> and added a
+> discussion link and on preview it went to the page's discussion page. I
+> don't normally have a toplevel /discussion page, but I also tried adding
+> one, and the link still doesn't link to it. Testcase? --[[Joey]] 
+
+>> I can reproduce this on <http://blog.liw.fi/posts/distributed-internet-witness-service/>:
+>> if I edit the page, then preview (no changes made), the "discussion" link at the bottom
+>> of the page points in the preview
+>> to <http://blog.liw.fi/discussion/>,
+>> whereas the saved page has it pointing to
+>> <http://blog.liw.fi/posts/distributed-internet-witness-service/discussion/>.
+>> I'll arrange so that you can edit the page to test this.
+>> --liw
+
+>> Joey suggested my wiki might be missing the FORCEBASEURL snippet from the misc.tmpl
+>> template, and he's right. Mea culpa: I had not diffed the various templates when upgrading
+>> and had missed that updated. [[done]] --liw
diff --git a/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn b/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn
new file mode 100644
index 000000000..5bab283fd
--- /dev/null
+++ b/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn
@@ -0,0 +1,24 @@
+The standalone 'markdown' utility is perfectly happy with an external link inside a `<h1>`, e.g.:
+
+    # Review of [Dwarf Fortress][]
+    ...
+    [Dwarf Fortress]: http://www.bay12games.com/dwarves/
+
+produces
+
+    <h1>Review of <a href="http://www.bay12games.com/dwarves/">Dwarf Fortress</a></h1>
+
+but when I try to use this construct in an ikiwiki page, I get 
+
+    <h1>Review of [Dwarf Fortress][]</h1>
+
+It works fine with h2 and deeper.  The square brackets also appear in the output of an [[ikiwiki/directive/inline]] directive in archive mode, I haven't tried non-archive mode.
+
+> I think you were confused by markdown's slightly wacky mix of square brackets and parens.
+> The url in a markdown link goes in parens, not square brackets. For example:
+
+# [Google](http://google.com/)
+
+> [[done]] --[[Joey]]
+
+>> It works here but it definitely does *not* work on my wiki; but on further experimentation, I believe my problem is being caused by JasonBlevins' [h1title](http://code.jblevins.org/ikiwiki/plugins.git/plain/h1title.pm) plugin.
diff --git a/doc/bugs/html5_support.mdwn b/doc/bugs/html5_support.mdwn
index 41f955e51..09ded91da 100644
--- a/doc/bugs/html5_support.mdwn
+++ b/doc/bugs/html5_support.mdwn
@@ -1,47 +1,44 @@
-Some elements of [HTML5](http://www.whatwg.org/specs/web-apps/current-work/multipage/) can be safely supported by ikiwiki. There are [several differences between HTML4 and HTMl5](http://www.w3.org/TR/html5-diff/). Unsupported new elements _should degrade gracefully_.
+Some elements of
+[HTML5](http://www.whatwg.org/specs/web-apps/current-work/multipage/) can be
+safely supported by ikiwiki. There are [several differences between HTML4 and
+HTML5](http://www.w3.org/TR/html5-diff/).
 
-> In the `origin/html` branch, there is an old work in progress to make
-> ikiwiki use html 4 instead of xhtml. If that could be brought forward and
-> finished then the plan has been to switch ikiwiki over to doing html 4.
-> I don't think it makes sense to try to make it support both xhtml and
-> html, it would complicate the code for no benefit.
-> 
-> I think that is the best route toward supporting html 5 as well. Get
-> ikiwiki doing html 4 first and the changes needed to get to 5 from there
-> should be small. Probably just changing some doctypes and a few other
-> small changes which could be kept in a branch, or even shipped in ikiwiki
-> mainline as an alternate set of templates. Some of the changes, like
-> supporting new html 5 tags in the htmlscrubber, can be done in mainline.
-> (Like was already done for the html 5 video and audio tags.)
->
-> This approach seems much more maintainable going foward than rolling a
-> html 5 branch immediatly and trying to keep that continually up-to-date
-> with mainline ikiwiki that is still using xhtml. --[[Joey]]
+* [HTML5 branch](http://git.webconverger.org/?p=ikiwiki;h=refs/heads/html5)
+* [ikiwiki instance with HTML5 templates](http://natalian.org)
 
-However as an [early adopter](http://en.wikipedia.org/wiki/Early_adopter) I would like to start using HTML5 as much as possible. The more pragmatic solution would be to use elements supported by the browsers of your readership I guess. I'm following other early adopters like [Anne](http://annevankesteren.nl/) for clues on how to proceed.
+# HTML5 Validation and t/html.t
 
-* [Initial patch](http://git.webconverger.org/?p=ikiwiki;a=commit;h=2e2bb3f74f5000b1269142d6f9bdf1bcb4075ca4)
+[validator.nu](http://validator.nu/) is the authorative HTML5 validator,
+however it is almost impossible to sanely introduce as a build dependency
+because of its insane Java requirements. :( I test locally via
+[cURL](http://wiki.whatwg.org/wiki/IDE), though Debian packages cannot be built
+with a network dependency.
 
-> I can't figure out how to pull from this repository.
->> Sorry! I have fixed the cloneurl file to read `git clone git://webconverger.org/git/ikiwiki`
+In the future, hopefully ikiwiki can test for valid HTML5 using [Relax NG
+schema](http://syntax.whattf.org/) using a Debian package tool
+[rnv](http://packages.qa.debian.org/r/rnv.html).
 
-I'm unsure how to turn off the test validation by the very old [wdg-html-validator](http://packages.qa.debian.org/w/wdg-html-validator.html). So I have been unable to test my initial patches as I can't build ikiwiki. I would like to know how to edit the rules/Makefile to temporarily disable this.
+# HTML5 migration issues
 
-> Don't run ¨make test" ... --[[Joey]] 
->> I don't quite grok debhelper7 [rules](http://git.ikiwiki.info/?p=ikiwiki;a=blob;f=debian/rules).
+# [article](http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-article-element) element
 
->>> Well, ok :-) `rm t/html.t` or, add an empty `override_dh_auto_test` rule.
->>> --[[Joey]] 
+This element is poorly supported by browsers. As a workaround, `style.css` needs:
 
-[validator.nu](http://validator.nu/) incidentally is **the** HTML5 validator, however it is almost impossible to sanely introduce as a build dependency because of its insane Java requirements. :( I test locally via [cURL](http://wiki.whatwg.org/wiki/IDE), though Debian packages cannot be built with a network dependency.
+	article {
+		display: block;
+	}
 
-# Notes
+Internet Explorer will display it as a block, though you can't seem to be further control the style.
 
-* the [time element](http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element) ideally needs the datatime= attribute set with iso8601 time
-* I suspect the migration to the new semantic elements of HTML5 like article, header & footer to take some time, due to browser support. Though they sure make the template code look much nicer.
-* `<br>` and too many `<div>`s usually indicates poor semantics.
-  > YMMV, but I tend to find that kind of concern counterproductive.
-  > --[[Joey]] 
+# Validator complains with no h1-h6 in header
 
-* Many of the header `<span>`s should be proper [header elements](http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements)
-  > See [[todo/Option_to_make_title_an_h1__63__]] for why not. --[[Joey]] 
+* [#509](http://bugzilla.validator.nu/show_bug.cgi?id=509)
+
+## Time element
+
+The [time element](http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element) ideally needs the datatime= attribute set by a template variable with what [HTML5 defines as a valid datetime string](http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-global-date-and-time-string).
+
+As a workaround:
+
+	au:~% grep timeformat natalian.setup
+	timeformat => '%Y-%m-%d',
diff --git a/doc/bugs/no_easy_way_to_wrap_HTML_container_around_a_set_of_inlined_pages.mdwn b/doc/bugs/no_easy_way_to_wrap_HTML_container_around_a_set_of_inlined_pages.mdwn
new file mode 100644
index 000000000..85c2d0c6c
--- /dev/null
+++ b/doc/bugs/no_easy_way_to_wrap_HTML_container_around_a_set_of_inlined_pages.mdwn
@@ -0,0 +1,9 @@
+The [[ikiwiki/directive/inline]] directive applies a template to each page-to-be-inlined, but the loop over the pages is in the Perl, not the template itself.  This means if I want to wrap a container `<div>` or a `<table>` or whatever around the entire set of inlined pages, I can't do it by just editing the template.  In fact, I think the only way to do it without hacking any Perl is with a wrapper template directive, e.g.
+
+    \[[!template id="wrapinline" pages="..."]]
+
+with a template definition like
+
+    <div id="foo">\[[!inline ... pages="<TMPL_VAR raw_pages>"]]</div>
+
+It would be much more convenient if the loop over pages happened in the template, allowing me to just stick whatever markup I want around the loop.
diff --git a/doc/bugs/pagespec_can__39__t_match___123__curly__125___braces.mdwn b/doc/bugs/pagespec_can__39__t_match___123__curly__125___braces.mdwn
new file mode 100644
index 000000000..dee1e9891
--- /dev/null
+++ b/doc/bugs/pagespec_can__39__t_match___123__curly__125___braces.mdwn
@@ -0,0 +1,44 @@
+I want match pages which have actually curly braces in the names (like this one), but this matches a lot of pages without the braces in their names :( :
+
+[[!inline show="3" feeds="no" archive="yes" pages="*_{*}_*"]]
+
+(note: the inline above has been restricted to 3 matches to keep this page
+concise. Hopefully it is still clear that this page is not in the output set,
+and the 3 pages in the output set do not contain curly braces in their
+titles).
+
+When escaped, it doesn't work at all:
+
+[[!inline show="3" feeds="no" archive="yes" pages="*_\{*}_*"]]
+
+[[!inline show="3" feeds="no" archive="yes" pages="*_{*\}_*"]]
+
+More tests:
+
+"\*{\*":
+
+[[!inline show="3" feeds="no" archive="yes" pages="*{*"]]
+
+"\*\\{\*":
+
+[[!inline show="3" feeds="no" archive="yes" pages="*\{*"]]
+
+> This is due to the current handling of quoting and escaping issues
+> when converting a pagespec to perl code. `safequote` is used to
+> safely quote an input string as a `q{}` quote, and it strips
+> curlies when doing so to avoid one being used to break out of the `q{}`.
+> 
+> Alternative ways to handle it would be:
+>
+> * Escape curlies. But then you have to deal with backslashes
+>   in the user's input as they could try to defeat your escaping.
+>   Gets tricky.
+>
+> * Avoid exposing user input to interpolation as a string. One
+>   way that comes to mind is to have a local string lookup hash,
+>   and insert each user specified string into it, then use the hash
+>   to lookup the specified strings at runtime. [[done]]
+> 
+> --[[Joey]] 
+
+Thank you! I'll try it. --Ivan Z.
diff --git a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
index 4a83f9ec8..c54376aa1 100644
--- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
+++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
@@ -231,3 +231,44 @@ So, looking at your meta branch: --[[Joey]]
 >> handling, since po contains a workaround for that, and it's probably
 >> acceptable to use potentially slow methods to handle this case.)
 >> --[[Joey]] 
+
+>>> I'm glad to implement whatever decision we'll make, but I don't
+>>> clearly understand what this discussion's conclusion is. It seems
+>>> like we agree at least on one point: meta page titles shall not be
+>>> displayed all over the place by default; I have therefore disabled
+>>> `meta_overrides_page_title` by default in my `meta` branch.
+>>> 
+>>> My next question is then: do we only want to satisfy the `po`
+>>> plugin needs? Or do we want to allow people who want this, such as
+>>> [[madduck]], to turn on a config switch so that meta page titles
+>>> are displayed as wikilinks titles? In the latter case, what level
+>>> of configurability do we want? I can think of a quite inelegant
+>>> way to implement full configurability, and provide a configuration
+>>> switch for every place where links are displayed, such as
+>>> wikilinks, parentlinks, etc., but I don't think the added bonus is
+>>> worth the complexity of it.
+>>> 
+>>> I think we can roughly split the needs into three categories:
+>>> 
+>>> 1. never display any modified page title in links; this is the
+>>>    current behaviour, and we should keep it as the default one
+>>> 2. display modified page titles only at well chosen places; that
+>>>    could be "manual" wikilinks, I mean those generated by the
+>>>    `link`, `camelcase` & al. plugins, the recentchanges page, and
+>>>    maybe a few other places; keep the usual pagename-based title
+>>>    for every other link, such as the parentlinks ones.
+>>>    The inter-page dependency problem remains, though. As a first
+>>>    step, I'm in favour of the "slow, but correct" implementation,
+>>>    with a big warning stating that enabling this option can make
+>>>    a wiki really sluggish; if someone really wants this to work
+>>>    fast, he/she'll implement a clever dependency handler :)
+>>> 3. display modified page titles all over the place; IMHO, we
+>>>    should implement only the bits needed so that the `po` plugin
+>>>    can set this up, rather than provide this as
+>>>    a user-configurable option.
+>>> 
+>>> So my question is: do we want to implement the #2 case, or not?
+>>> I propose myself to only implement #1 and #3 to start with, but do
+>>> it in a way that leaves room for #2.
+>>> 
+>>> --[[intrigeri]]
diff --git a/doc/bugs/pipe-symbol_in_taglink_target.mdwn b/doc/bugs/pipe-symbol_in_taglink_target.mdwn
new file mode 100644
index 000000000..e467959be
--- /dev/null
+++ b/doc/bugs/pipe-symbol_in_taglink_target.mdwn
@@ -0,0 +1,25 @@
+[[!tag bugs wishlist]]
+
+Escaping pipe-symbol in [[taglink|ikwiki/directive/taglink]] targets doesn't work as I wanted:
+
+[[!taglink smth_with_a_pipe|about_the_\|-symbol]]
+[[!taglink smth_with_a_pipe|about_the_|-symbol]]
+
+as opposed to simple wikilinks:
+
+[[a link to smth with a pipe|about the \|-symbol]]
+[[a link to smth with a pipe|about the |-symbol]]
+
+And it seems to work in pagespecs:
+
+tagged:
+
+[[!map pages="tagged(about the |-symbol)"]]
+
+[[!map pages="tagged(about the \|-symbol)"]]
+
+link:
+
+[[!map pages="link(about the |-symbol)"]]
+
+[[!map pages="link(about the \|-symbol)"]]
diff --git a/doc/bugs/remove_plugin_and_untracked_files.mdwn b/doc/bugs/remove_plugin_and_untracked_files.mdwn
new file mode 100644
index 000000000..07408c3bc
--- /dev/null
+++ b/doc/bugs/remove_plugin_and_untracked_files.mdwn
@@ -0,0 +1,6 @@
+The [[plugins/remove]] plugin does not report an error if git rm fails. (It
+probably doesn't if other VCS backends fail too). This can happen for example
+if a page in your source directory is not a tracked file for whatever reason
+(in my case, due to renaming the files and forgetting to commit that change).
+
+ -- [[Jon]]
diff --git a/doc/bugs/tagged__40____41___matching_wikilinks.mdwn b/doc/bugs/tagged__40____41___matching_wikilinks.mdwn
new file mode 100644
index 000000000..1bd556f50
--- /dev/null
+++ b/doc/bugs/tagged__40____41___matching_wikilinks.mdwn
@@ -0,0 +1,17 @@
+It may be that I'm simply misunderstanding something, but what is the rationale
+for having `tagged()` also match normal wikilinks?
+
+> It simply hasn't been implemented yet -- see the answer in [[todo/tag_pagespec_function]]. Tags and wikilinks share the same underlying implementation, although ab reasonable expectation is that they are kept separate. --Ivan Z.
+
+The following situation.  I have `tagbase => 'tag'`.  On some pages, scattered
+over the whole wiki, I use `\[[!tag open_issue_gdb]]` to declare that this page
+contains information about an open issue with GDB.  Then, I have a page
+`/tag/open_issues_gdb.mdwn` that essentially contains `\[[!map
+pages="tagged(open_issue_gdb)"]]`.  So far, so good: this page indeed does list
+all pages that are tagged like this.  But now, when I add in `/gdb.mdwn` a link
+to this page, like `\[[Open Issues|tag/open_issue_gdb]]`, then `/gdb.mdwn`
+itself shows up in the map on `tag/open_issues_gdb.mdwn`.  In my understanding
+this is due to the wikilink being equal to a `\[[!tag ...]]`.  What's the
+rationale on this, or what am I doing wrong, and how to achieve what I want?
+
+--[[tschwinge]]