Brian,

That's an interesting technique for getting around the parser's hard- coded insertion of a double '\n' prior to the text returned by a parser function.

I've struggled with this (and various other bogus insertions of unwanted line breaks) in conjunction with my own parser functions. The technique I've been using so far (which I learned from, I think, our NZ compatriots who did the category tree extension) is to use a, ah, "customized" structure for the return value from the parser function itself, specifically, using the insertStripItem function of the parser:

return $parser->insertStripItem( $output, $parser->mStripState );

(This method is now cited on the Parser Functions manual: http://www.mediawiki.org/wiki/Manual:Parser_functions )

This method has mostly taken care of that particular problem, for me ... and it avoids the extra (but clever) layer of the companion template required in your method.

Does anyone have any comments to offer that compare & contrast between these two methods, or maybe some third method for avoiding intrusion of extraneous line breaks into output of parser functions that would be even better?

Paul

On Aug 13, 2009, at 2:12 PM, Brian wrote:

I created a simple parser function that inserts a one line div into the page. It worked as expected except in the case where it was the first bit of wikitext in the article. In that case, the parser inserted <p><br/></ p> into the page just before the div creating an ugly gap that wasted space. I then discovered that if I wrote <nowiki></nowiki> just before my parser function that this paragraph block was ommitted and I got the expected behavior. So I ended up wrapping my parser function in a template of the same name that also inserts the nowiki code, and voila, problem "solved." !

/brian

______________ Paul C Lustgarten Applied Research, Enterprise 2.0 AT&T Labs - Research Florham Park, NJ +1 973 360 7206