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... |