Re: [Python-markdown-discuss] Python-Markdown 2.0 Release Candidate

[Ron G. <ro...@fl...>]

On Mar 23, 2009, at 6:05 PM, Waylan Limberg wrote:

>
>> Wikipedia allows wikilinks that start with an underscore;
>> markdown.py doesn't.
>
> Yes it does. Any allowed character it allowed at any location in the  
> link.
>

Ah.  There is a bug there, but it's not what I thought:

 >>> markdown.markdown('[[foo _baz_]]',['wikilinks'])
u'<p>[[foo <em>baz</em>]]</p>'

Apparently it doesn't like _emphasis_ inside a wikilink.

>> In general, I think the wikilink canonicalization algorithm ought to
>> have the property that two wikilinks that look like the "ought" to be
>> the same actually are the same.  [[WikiLink]] and [[wiki link]] are
>> perhaps arguable, but [[wiki link]] and [[wiki  link]] aren't IMO.
>>
>
> The way things work now is that what you put between brackets is
> exactly what you get in the label. A long standing annoyance of mine
> is wikilink systems which don't allow me to format the label how I
> want as long as I use the allowed characters. This extension does. So,
> if I put double spaces in my link, then I want that to carry through
> to the label.

Yes, to the *label*, but not to the URL.

> Of course, the link itself has to be altered as spaces are not allowed
> in urls. So I did the simplest thing possible. I replaced the space
> with an underscore. Although it's not too sophisticated, it does
> return what should be valid urls consistently.

This is certainly arguable on both sides.  IMO, there should be a  
canonicalization process, otherwise you risk getting multiple pages  
that really should be the same page.  I think [[John F Kennedy]],  
[[John F. Kennedy]] and [[John F  Kennedy]] should all point to the  
same place.  But reasonable people could disagree.


>
>>> I think. However, perhaps it would make sense to make this
>>> configurable.
>
> I see a few options here:
>
> 1. Improve the space replacement code, otherwise leaving things as is
> and tell people to write their own extension. Perhaps even subclassing
> ours to get their desired behavior.
>
> 2. Allow the config to accept a callable and provide a default which
> formats the wikilink for insertion into the url.
>
> 3. Allow the config to accept a callable that builds the entire url.
> This would remove the need for the 'start_url' and 'end_url' configs
> as they would be part of the callable.
>
> 4. Allow the config to accept a callable that builds the entire <a>
> element and returns it. Of course, we provide a default. For example,
> this would also allow people to easily override the default to add a
> class indicating whether the link points to an existing page or not.
> This would remove the need for all the existing config options.
>
> Personally, I think option 1 is good enough. One can always write
> their own extension that fits their needs. However, if we're going to
> really make things configurable, then we might as well go all the way
> with 4. My only concern about that it that it requires any
> customization to require working with ET. That might be too high a
> barrier of entry for some. Despite my preference, I suppose the same
> could be said of option 1 (requiring them to write their own extension
> to change the behavior). Which leaves us with 2 or 3. Any thoughts?

I like option 3 myself.  Makes it simpler and more powerful, which is  
always a winning combination in my book.

rg