--- Comment #9 from Brad Jorsch <> ---
(In reply to andré from comment #8)
> So you are saying that problems with the implementation of these new
> features interfere with this extension ?

It's not a problem with those features, it's a design requirement.

We had to deal with that requirement when creating Scribunto, too.

> I'm assuming that all this extension does is scan the page, taking the
> variable definitions and replacing all instances using the defined
> variables, before any other parsing of the page.  The result is a page that
> shows no evidence of the extension.

I haven't checked, but I'd imagine the model is more that when the parsing
process calls the hook for #vardefine it sets some internal state, and when it
calls the hook for #var then it returns that internal state. Much like how with
Cite a <ref> sets some internal state and <references> uses that to construct a
list of references.

> Maybe there needs to be a processing priority established ?

Let's not add even more passes to the parser. The Parsoid folks already want to
do that for Cite (and do do it in Parsoid).

> Maybe you can explain how any problems with the new VisualEditor and Parsoid
> are not orthogonal to this extension ?

Because wikitext needs to be parsed?

> I'm not trying to distract you from solving VisualEditor problems,

Not my department anyway.

You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to