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

[Waylan L. <wa...@gm...>]

On Mon, Mar 23, 2009 at 6:55 PM, Ron Garret <ro...@fl...> wrote:
>
> On Mar 23, 2009, at 3:27 PM, Yuri Takhteyev wrote:
>
>>>> 1.  The wikilink behavior has changed in a non-backwards-
>>>> compatible way.
>>>>  Before, [[WikiLink]] and [[wiki link]] were equivalent.  Now they
>>>> are not.
>>>>  Personally, I preferred the old way.
>>
>> The new way is closer to what Wikipedia does, which is a big plus
>
> Perhaps, but if that's the goal then actually doing it the way
> Wikipedia does it would be even better than just being "way closer."
> Wikipedia contracts multiple spaces down to one, but markdown.py
> doesn't.

Ok, I hadn't considered that one, and it is a little strange but see
my comments below.

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

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

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.

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

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg