Re: [Python-markdown-discuss] GSoC progress

[Yuri T. <qar...@gm...>]

> What is the profit of dropping current inline pasterns? We still need
> some functions, that would create DOM element from regexp match object.
> Maybe we should just refactor current inline patterns regexps ?
> Now I'm fixing bugs, and some of them require Inline patterns changes.

The profit is from switching to something simpler, faster and more
accurate, while maintaining the extensibility.  My guess is that
changing inline patterns to be text-in-text-out will make them simpler
(some will just become regular expressions), easier to understand,
will likely be faster, and will allow us to handle them in the same
way as all other implementations do.  (We might just borrow their
regular expressions in some cases.)

The current implementation (using DOM) creates a few serious issues
for inline patterns, which I don't think can be solved in any easy
way.  We are relying on regular expressions to match patterns, but
those cannot span multiple nodes.  This means, for instance, that we
can either make **[foo](/foo.html]** work, or [**foo**](foo.html), but
not both.  If we run the link pattern first, then the first string
turns into ("**", <a dom node>, "**").  We now cannot run a regular
expression across this.  If we apply the **...** pattern first, then
the second expression becomes ("[", <a dom node>, "](foo.html)") and
now we cannot match the link pattern.  Which is why my suggestion
(which I haven't had time to implement) has been to switch to simple
text-in-text-out implementation of the patterns:

1. link pattern turns  "**[foo](/foo.html]**" into "**<a
href='/foo.html'>foo</a>**"
2. bold pattern turns "**<a href='/foo.html'>foo</a>**" into "<b><a
href='/foo.html'>foo</a></b>"

By only using this method for inline patterns I think we would get the
best of both worlds.  In particular, we retain the concept of the tree
for high level elements and make it possible to write sophisticated
extensions, which do certain changes to certain kinds of blocks.  But
we also will be handling basic tags like other implementations.

  - yuri

-- 
http://sputnik.freewisdom.org/