|
From: Waylan L. <wa...@gm...> - 2008-09-05 20:40:12
|
As many of you know, the wikilink extension is not currently working.
Initially we had some problems with the way inline placeholders were
implemented but that has been resolved.
The problem is that CamelCase words that correctly appear in other
parts of the markup are mistakenly being identified as wikilinks.
Consider the following cases:
<a href="http://example.com/">RealLink</a>
<http://example.com/AutoLink>
[MarkdownLink](http://example.com/)
In all three cases, the label is identified as a wikilink and we get
nested links i.e.:
<a href="http://example.com/"><a href="/RealLink/"
class="wikilink">RealLink</a></a>
In the past this was not a problem because any markup in the labels
was ignored. Now that that bug is squished, I need a way to tell
markdown to not run the WikiLink pattern against the label. There are
currently two mechanisms to do that. One it to set each label as an
AtomicString. However, then we would again be back were we were with
nested markup being ignored in labels.
The other solution is to reorder the InlinePatterns. The problem is,
we don't want the wikilink pattern to match against camelcase URLs
(i.e. "AutoLink" of the above autolink) so the wikilink pattern must
run after all the various link patterns. Additionally, for various
other reasons (such as allowing asterisk in URLs) the link patterns
must be run before most other inline patterns - so we can't set the
labels as AtomicString *and* reorder either.
What this means is that, unless I'm missing something obvious, there
is no way to reliably match CamelCase wikilinks without getting nested
links when a label contains a CamelCase word. Interestingly, it
occurred to me that if InlinePattern was passed the parent element, we
could test ``parent_elem.tag != 'a'``, but even then, if that
CamelCase word is nested in strong or em tags, that test would fail.
Besides, I can't think of any other use for doing that.
Therefore, I'm thinking we will need to throw out the wikilink
extension as it currently exists. Alternatively, I could replace the
regex with a pattern that matched bracketed links (i.e. [[somelink]])
regardless of case as someone recently suggested, but then anyone
using the extension would need to update their documents to the new
syntax.
Any thoughts?
PS: If I change to [[bracketed links]], I will also change the name of
the extension to avoid any confusion. Although, probably not a drastic
change - say from "wikilink" to "wikilinks" (what it should have been
called to begin with). That way, the extension users will be forced to
note the difference and be alerted that something changed.
--
----
Waylan Limberg
wa...@gm...
|