[got to this one a little late... for those who've forgotten, empty lines in the javascript output of LJ's parser hook extension were being enclosed in <p></p> by the parser]
On Mon, 06 Feb 2006 18:40:13 +0100, Tels wrote:
Moin,
On Monday 06 February 2006 06:17, LJ wrote:
Cynicism aside Rob, I appreciate the reply.
Did a bit more digging, and found this 'bug' in bugzilla: http://bugzilla.wikimedia.org/show_bug.cgi?id=1772 Seems like it's been around awhile. I updated the version, added a note, and voted for it.
For the time being I can work around it by limiting the text I insert between my tags (no newlines). However, I'd like to publish my extension, and I'm unlikely to do so if I have to have the caveat of: 'you have to format the tagged content just-so...'.
Don't know if my previous global flag or callable method ideas have much merit ( or are feasible to integrate into the parser structure ). But, it'd be nice if a developer latched on to them... :)
Btw, the Graph::Easy extension (returing HTML) also runs into this. Even when you add no emoty lines and leading spaces, mediawiki seems to insert a paragraph every N lines or so. This of course creates wierd empty spaces in the generated table :(
In the end I stripped *ever* \n from the output and now return a gigantous long line.
A way to switch this off from my extension would be great, because the emitted HTML becomes impossible to debug or inspect.
I've had a similar problem with cells for a summary table being too bloated when the content is enclosed in <p></p> tags.
My solution was the "'long way' around" as LJ put it - preemptively add identifiable paragraph tags within the tag rendering hook, within an identifiable block, and then remove them in a ParserBeforeTidy hook. Doing this properly also required escaping any preexisting such block markers in a ParserBeforeStrip hook - all in all an inefficient schlep and I agree that a method of indicating to the parser that it should avoid paragraph tag insertion for any given hook would be useful.
Ultimately it works though, without needing to return all content on a single line or otherwise give up formatting, and the approach could be adapted for newlines - the tag rendering function would enclose itself in the block markers and convert empty lines to the pair of identifiable paragraph tags.
For reference, the tags I'm using are <p class="remove"> and </p >, and the block markers are __STARTREMOVEPARA__ and __ENDREMOVEPARA__.
Also, LJ, you originally wrote:
a section or two above, it's stated that when you forcibly render text with the parser, you can turn off the <p> tags with a simple 'false'
Iirc, this only applies to the first line of text provided to the parse function - later lines will be enclosed in <p></p> tags as usual.