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