As it turns out, that only requires a minor modification to the parser: patch for txp4.6-dev
The patch assumes that every plugin developer uses a 3 character plugin prefix, which they should if they follow the guidelines. The patch doesn’t force people to use the new notation; it just offers it as an alternative.

Re: Making plugins first-class citizens

That would be nice, indeed, but could clash with importing namespaced xml documents. And I think you need to do a minor change in splat() function too, unless I’ve overlooked it in your patch (sorry then).

This looks nice. What would happen if a plugin author chose a prefix with a different length?

With the patch I provided, <long:tag> and <i:m to=“short”> would not be recognized as tags. Those would have to be written as <txp:long_tag> and <txp:i_m to=“short”>
However, it’s easy to rewrite the patch to support variable length prefixes. I chose a fixed width of 3 chars, because that’s what our plugin guidelines specify. Actually, the guidelines specify 3 letters, which is even more specific.

Looking at the currently registered plugin prefixes:

290 three letter prefixes

4 two letter prefixes (it, ja, jk, vg)

4 three character prefixes (an7, e26, ob1,r11)

One could argue that allowing 2-char prefixes gives an unfair advantage, because shorter tends to be more popular.
I’ll update the first post with new patches for strict 3 letter, 3 character, 2-3 character prefixes. The latter can be changed to longer prefixes by changing 2 characters in the patch.

Re: Making plugins first-class citizens

Very cool. And backwards compatible too, as it’s just an extension for permitting simpler syntax (so no plugin changes required). Reinforcing the three-character prefix in order to take advantage of this feature is a reasonable restriction/convention and actually makes the case for proper prefixing stronger, because plugin authors will surely want their user base to do less typing to work with their public-side plugins :-)

Haven’t tested it yet, but it does look as though etc is right: splat() may need changing to parse and display attributes from first-class plugins in the tag trace. The trick is to do this efficiently, since it’s called a lot.

Regarding the XML import, it shouldn’t be a problem as tags need registering prior to execution to avoid throwing the warning and (ultimately, one day) failing outright. So unless the XML document is handled by a plugin that auto-registers namespaced tags within Textpattern, we should be covered. Ummm, I think…

I’m all for this. And I’d love to see some stuff in the parser like Gocom mentioned in the post to which gomedia linked. I was trying to find that post the other day and failed, thanks!

Re: Making plugins first-class citizens

It’s not really different from TXP tags, so those would then potentially clash with XML documents as well, I think.

Sure, but every new prefix results in the clash probability increase. Suppose that you need to export some articles as Excel sheet, which includes plenty of <mso:tags />, then using any mso_plugin would be problematic.

splat() gets the string of attributes as input, not the tagname itself.

Re: Making plugins first-class citizens

I’ve made some modifications in parse() (running in the wild here) to cache the results of preg_split. The modified parser itself is much faster, but the overall performance is just a little better, because most of runtime is taken by db calls / udfs. It’s still worth implementing, at the risk of sha1 collision (but then it will be the first known one :).

Re: Making plugins first-class citizens

Re: Making plugins first-class citizens

Superb, thanks. Hadn’t considered EvalElse() but from reading the patch, it seems to allow lovely constructs like:

<smd:if ...>
Yay :-)
<smd:else />
Nay :-(
</smd:if>

effectively retrofitting every plugin with a personal else tag. If that’s true (is it?), it’ll make multiple nested conditional pages easier to follow, because you can marry else tags up with a plugin’s opening / closing tags by prefix. Brilliant. Of course there’s every chance I’ve misinterpreted the patch out of context with the source itself.