Hello everyone,
I'd like to propose a very small update, which would have no
backwards-compatibility problems, and would bring PHP closer to
standards compliance.
The update I'd like to propose is to the Zend Highlighter for PHP,
specifically related to the highlight_file and highlight_string
functions, as well as the php -s command.
My proposal is a very simple one, which would add a third parameter,
which would be optional, which would select between "inline" styling,
and external styling. The proposed syntax for highlight_file would be:
mixed highlight_file (string $filename [, bool $return= false [, bool
$inline= true]]);
Currently, syntax highlighting is done inline, by means of the style
attribute of the span tag (<span style="color: #FFFFFF">...</span>). My
proposition would be for a "class" attribute to be set instead of the
style attribute, based on the value of $inline (<span
class="phpcomment">...</span>).
The issue this modification is intended to fix is that many developers
who intend to provide syntax highlighting in their project end up
rolling their own code for such. By providing external styling code
rather than inline styling, it makes it possible to modify the style of
all highlighted code, without modifying the code itself. It also
provides the capability to extend the viewing experience with
Javascript, such as code folding functionality.
I've taken the liberty to produce a very quick and dirty patch, which is
by no means complete, but provides a cursory example of what I intend.
I'd like to clarify that this is the first time I've modified PHP's
code, and I know very little C. The only modifications I've done for PHP
in the past have been in the PHP-GTK branch, attempting to fix the
documentation generator to work with the non-standard extension
structure. If I've submitted my proposal poorly, I apologize.
Please offer any comments you have.
Thank you,
Justin Martin aka FrozenFire
2009/4/2 Justin Martin frozenfire@thefrozenfire.com:
My proposal is a very simple one, which would add a third parameter,
which would be optional, which would select between "inline" styling,
and external styling. The proposed syntax for highlight_file would be:
+1 :)
-Hannes
Hi Justin
2009/4/2 Justin Martin frozenfire@thefrozenfire.com:
Hello everyone,
I'd like to propose a very small update, which would have no
backwards-compatibility problems, and would bring PHP closer to
standards compliance.
inline styles are standards compliant, but I know what you mean,
inline styles aren't always nice to work with ;)
The update I'd like to propose is to the Zend Highlighter for PHP,
specifically related to the highlight_file and highlight_string
functions, as well as the php -s command.My proposal is a very simple one, which would add a third parameter,
which would be optional, which would select between "inline" styling,
and external styling. The proposed syntax for highlight_file would be:mixed highlight_file (string $filename [, bool $return= false [, bool
$inline= true]]);Currently, syntax highlighting is done inline, by means of the style
attribute of the span tag (<span style="color: #FFFFFF">...</span>). My
proposition would be for a "class" attribute to be set instead of the
style attribute, based on the value of $inline (<span class="phpcomment">...</span>).
I have written a quick and easy patch for this [1], which instead of
adding a new parameter to the highlight functions adds 6 new ini
settings:
highlight.inline_class (yes I know the name is weird, but thought it
was better than highlight.use_classes or similar)
highlight.class_(comment|default|keyword|html|string)
Each of the highlight.class_* sets a default class to use, these are
editable so they won't conflict with class names your style might have
defined to something else, therefore making it more modular. A simple:
$ php -d highlight.inline_class=1 -s -f file.php
Will now give:
<span class="xxx"><span class="yyy">...</span></span>
Instead of before giving:
<span style="color: xxx"><span style="color: yyy">...</span></span>
I thought using ini settings was more in place with how the current
API works so I went that way. The patch isn't perfect but it does its
job, note that its written for PHP_5_3, but since we're in RC stage
theres really no chance of it getting added.
The issue this modification is intended to fix is that many developers
who intend to provide syntax highlighting in their project end up
rolling their own code for such. By providing external styling code
rather than inline styling, it makes it possible to modify the style of
all highlighted code, without modifying the code itself. It also
provides the capability to extend the viewing experience with
Javascript, such as code folding functionality.I've taken the liberty to produce a very quick and dirty patch, which is
by no means complete, but provides a cursory example of what I intend.I'd like to clarify that this is the first time I've modified PHP's
code, and I know very little C. The only modifications I've done for PHP
in the past have been in the PHP-GTK branch, attempting to fix the
documentation generator to work with the non-standard extension
structure. If I've submitted my proposal poorly, I apologize.Please offer any comments you have.
Thank you,
Justin Martin aka FrozenFire--
[1] http://www.paste2.org/p/176166
--
Kalle Sommer Nielsen
kalle@php.net
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
Hi Justin
Attached a patch instead, hopefully this will work ;)
--
Kalle Sommer Nielsen
kalle@php.net
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
Hi Justin
Attached a patch instead, hopefully this will work ;)
I really do like this idea :) Let's just commit it.
I would however like ot see the "naming" stucture Justin used in the
first example by prefixing the CSS classnames by "php". This will
greatly help the inclusion into other considering that "comment" and
"default" are widely used (not sure about the other ones) for general
purposes usage (see google codesearch for example).
Cool work, do we go by adding 6 new ini settings and making sure they
are prefixed by default?
Also I guess we'll have to attach a css file with that? Inline css at
the top of the generated highlighted block maybe?
--
Slan,
David
Also I guess we'll have to attach a css file with that? Inline css at
the top of the generated highlighted block maybe?
I thought the purpose was to allow external styling?
Cheers,
Rob.
http://www.interjinn.com
Application and Templating Framework for PHP
David Coallier wrote:
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
Hi Justin
Attached a patch instead, hopefully this will work ;)
I really do like this idea :) Let's just commit it.
Hold your horses, lets not commit things hastily. I'm not a huge fan of
adding 6 new INI settings and I think have another idea so we can avoid
this and still offer more flexibility.
I would however like ot see the "naming" stucture Justin used in the
first example by prefixing the CSS classnames by "php". This will
greatly help the inclusion into other considering that "comment" and
"default" are widely used (not sure about the other ones) for general
purposes usage (see google codesearch for example).Cool work, do we go by adding 6 new ini settings and making sure they
are prefixed by default?Also I guess we'll have to attach a css file with that? Inline css at
the top of the generated highlighted block maybe?
No, the user would be responsible for producing the CSS sheet that they
want.
Scott
Hi Scott
2009/4/2 Scott MacVicar scottmac@php.net:
David Coallier wrote:
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
Hi Justin
Attached a patch instead, hopefully this will work ;)
I really do like this idea :) Let's just commit it.
Hold your horses, lets not commit things hastily. I'm not a huge fan of
adding 6 new INI settings and I think have another idea so we can avoid
this and still offer more flexibility.
Sure 6 new INI settings sounds alot, but thinking about it theres
already 6 to control the current (bg, default, comment, html, keyword
& string) and 5 of these new ones is to control classes if theres a
class naming conflict then a user can customize. So only one setting
is needed to enable this feature.
But if you have a better way around this then I'm all ears :)
I would however like ot see the "naming" stucture Justin used in the
first example by prefixing the CSS classnames by "php". This will
greatly help the inclusion into other considering that "comment" and
"default" are widely used (not sure about the other ones) for general
purposes usage (see google codesearch for example).Cool work, do we go by adding 6 new ini settings and making sure they
are prefixed by default?Also I guess we'll have to attach a css file with that? Inline css at
the top of the generated highlighted block maybe?No, the user would be responsible for producing the CSS sheet that they
want.Scott
--
Kalle Sommer Nielsen
kalle@php.net
Hi Scott
2009/4/2 Scott MacVicar scottmac@php.net:
David Coallier wrote:
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
Hi Justin
Attached a patch instead, hopefully this will work ;)
I really do like this idea :) Let's just commit it.
Hold your horses, lets not commit things hastily. I'm not a huge fan of
adding 6 new INI settings and I think have another idea so we can avoid
this and still offer more flexibility.Sure 6 new INI settings sounds alot, but thinking about it theres
already 6 to control the current (bg, default, comment, html, keyword
& string) and 5 of these new ones is to control classes if theres a
class naming conflict then a user can customize. So only one setting
is needed to enable this feature.But if you have a better way around this then I'm all ears :)
Wrap the whole highlighted block in a div with a class:
<div class="php-highlighted-code">
</div>
Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:
div.php-highlighted-code span.keyword { color: red; }
Cheers,
Rob.
http://www.interjinn.com
Application and Templating Framework for PHP
Wrap the whole highlighted block in a div with a class:
<div class="php-highlighted-code">
</div>Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the "default" names.
mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);
comment|default|keyword|html|string)
Array(
'div_wrapper' => 'xyz-cms-div-wrapper',
'default' => 'xyz-cms-default',
'etc' => 'xyz-cms-etc',
);
The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
-Chris
Hi Chris
2009/4/2 Chris Stockton chrisstocktonaz@gmail.com:
Wrap the whole highlighted block in a div with a class:
<div class="php-highlighted-code">
</div>Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the "default" names.mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);comment|default|keyword|html|string)
Array(
'div_wrapper' => 'xyz-cms-div-wrapper',
'default' => 'xyz-cms-default',
'etc' => 'xyz-cms-etc',
);The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
I must honest, I don't really like this approach (passing an array
with class names), I think INI calls are better, or even better if we
wrap it all into a "Highlight" class which could make the API alot
easier not only for classes, but also inline colors and perhaps even
more options later on.
-Chris
--
--
Kalle Sommer Nielsen
kalle@php.net
Wrap the whole highlighted block in a div with a class:
<div class="php-highlighted-code"> </div>Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the "default" names.mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);comment|default|keyword|html|string)
Array(
'div_wrapper' => 'xyz-cms-div-wrapper',
'default' => 'xyz-cms-default',
'etc' => 'xyz-cms-etc',
);The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
To be honest I don't think it's necessary, and on further reflection I
don't think you even need to offer an INI setting to change the class
name since if you want different styling you can merely wrap the the
main div in your own div and use another hierarchical level:
And the css:
div.alt-highlighting div.php-highlighted-code span.keyword
{
color: blue;
}
So being able to change the outer class name seems redundant.
Cheers,
Rob.
http://www.interjinn.com
Application and Templating Framework for PHP
Why not allow a class prefix as an option to the function?
Eg:
'php-highlighted-' as the prefix would produce things like
'php-highlighted-keyword'.
That way there's no risk of collision and there's no need to
over-complicated things.
2009/4/2 Robert Cummings robert@interjinn.com:
Wrap the whole highlighted block in a div with a class:
<div class="php-highlighted-code">
</div>Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the "default" names.mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);comment|default|keyword|html|string)
Array(
'div_wrapper' => 'xyz-cms-div-wrapper',
'default' => 'xyz-cms-default',
'etc' => 'xyz-cms-etc',
);The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.To be honest I don't think it's necessary, and on further reflection I
<div class="alt-highlighting"> <div class="php-highlighted-code"> </div> </div>
don't think you even need to offer an INI setting to change the class
name since if you want different styling you can merely wrap the the
main div in your own div and use another hierarchical level:And the css:
div.alt-highlighting div.php-highlighted-code span.keyword
{
color: blue;
}So being able to change the outer class name seems redundant.
Cheers,
Rob.http://www.interjinn.com
Application and Templating Framework for PHP
Why not just re-use the same highlight.*, they can be colors or classes...
<span class="%highlight.comment%"> or <span style="color: %highlight.comment">
you switch this based on "highlight.use_external_styles". You could also
add a: "highlight.add_stylesheet"
to add a default stylesheet created by PHP...
- Davey
Lewis Wright wrote:
Why not allow a class prefix as an option to the function?
Eg:
'php-highlighted-' as the prefix would produce things like
'php-highlighted-keyword'.That way there's no risk of collision and there's no need to
over-complicated things.2009/4/2 Robert Cummingsrobert@interjinn.com:
Wrap the whole highlighted block in a div with a class:
<div class="php-highlighted-code"> </div>Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the "default" names.mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);comment|default|keyword|html|string)
Array(
'div_wrapper' => 'xyz-cms-div-wrapper',
'default' => 'xyz-cms-default',
'etc' => 'xyz-cms-etc',
);The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.To be honest I don't think it's necessary, and on further reflection I
<div class="alt-highlighting"> <div class="php-highlighted-code"> </div> </div>
don't think you even need to offer an INI setting to change the class
name since if you want different styling you can merely wrap the the
main div in your own div and use another hierarchical level:And the css:
div.alt-highlighting div.php-highlighted-code span.keyword
{
color: blue;
}So being able to change the outer class name seems redundant.
Cheers,
Rob.http://www.interjinn.com
Application and Templating Framework for PHP
I do like using the same INI setting name which depends on the
use_external_styles setting.
However, no stylesheet should be automatically included. The highlight
functions do not produce a whole page, except in the case of a .phps
(PHP Source file). It should be up to the user to manage how they want
their stylesheet included.
Thanks,
Justin
Davey Shafik wrote:
Why not just re-use the same highlight.*, they can be colors or classes...
<span class="%highlight.comment%"> or <span style="color: %highlight.comment">
you switch this based on "highlight.use_external_styles". You could also
add a: "highlight.add_stylesheet"
to add a default stylesheet created by PHP...
- Davey
Lewis Wright wrote:
Why not allow a class prefix as an option to the function?
Eg:
'php-highlighted-' as the prefix would produce things like
'php-highlighted-keyword'.That way there's no risk of collision and there's no need to
over-complicated things.2009/4/2 Robert Cummingsrobert@interjinn.com:
On Thu, Apr 2, 2009 at 8:02 AM, Robert
Cummingsrobert@interjinn.com wrote:Wrap the whole highlighted block in a div with a class:
<div class="php-highlighted-code"> </div>Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the "default" names.mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);comment|default|keyword|html|string)
Array(
'div_wrapper' => 'xyz-cms-div-wrapper',
'default' => 'xyz-cms-default',
'etc' => 'xyz-cms-etc',
);The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.To be honest I don't think it's necessary, and on further reflection I
<div class="alt-highlighting"> <div class="php-highlighted-code"> </div> </div>
don't think you even need to offer an INI setting to change the class
name since if you want different styling you can merely wrap the the
main div in your own div and use another hierarchical level:And the css:
div.alt-highlighting div.php-highlighted-code span.keyword
{
color: blue;
}So being able to change the outer class name seems redundant.
Cheers,
Rob.http://www.interjinn.com
Application and Templating Framework for PHP
Why not allow a class prefix as an option to the function?
Eg:
'php-highlighted-' as the prefix would produce things like
'php-highlighted-keyword'.That way there's no risk of collision and there's no need to
over-complicated things.
It's repetitive and redundant. A single class in an encapsulating tag is
sufficient to target every rule within the block. That's how CSS is
supposed to work. Unfortunately, I'll grant that many people using CSS
just make all their class definitions global, or worse, use IDs for
nothing but CSS styling.
Cheers,
Rob.
http://www.interjinn.com
Application and Templating Framework for PHP
Hi David
2009/4/2 David Coallier davidc@php.net:
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
2009/4/2 Kalle Sommer Nielsen kalle@php.net:
Hi Justin
Attached a patch instead, hopefully this will work ;)
I really do like this idea :) Let's just commit it.
I would however like ot see the "naming" stucture Justin used in the
first example by prefixing the CSS classnames by "php". This will
greatly help the inclusion into other considering that "comment" and
"default" are widely used (not sure about the other ones) for general
purposes usage (see google codesearch for example).
We can just change the default values in zend_highlight.h to be
prefixed php-xxx aswell as in the ini.
Cool work, do we go by adding 6 new ini settings and making sure they
are prefixed by default?Also I guess we'll have to attach a css file with that? Inline css at
the top of the generated highlighted block maybe?
If a user wants to use css classes for highlight, then he will have
his own styling. I don't think we should attempt to "fix" it on php
level if this feature is enabled by adding a <style> section.
--
Slan,
David
--
Kalle Sommer Nielsen
kalle@php.net
I'm really liking the INI idea, including setting the default class
names for each element. However, I think it would be nice to have an
optional parameter to the functions to allow call-specific settings for
such things. This way, one can highlight their code in different ways,
in different contexts.
As well, although I realise we are already in RC, this can be added to
subsequent versions of both 5_2 and 5_3. Since it's rather
backwards-compatible, such shouldn't be an issue.
Another thing I'd like to ask is, would anyone be interested in writing
a more robust syntax highlighter? Currently, highlighting is restricted
to only a handful of available colours. It would be nice to be able to
have both general default style for code types (comment, keyword, etc),
as well as token-specific styling. This way, a truly robust syntax
highlighter is possible. It is probably a fairly large job, and
certainly not one that would be "just committed," but I believe it would
be of benefit to developers.
Thanks,
Justin
Kalle Sommer Nielsen wrote:
Hi Justin
2009/4/2 Justin Martin frozenfire@thefrozenfire.com:
Hello everyone,
I'd like to propose a very small update, which would have no
backwards-compatibility problems, and would bring PHP closer to
standards compliance.inline styles are standards compliant, but I know what you mean,
inline styles aren't always nice to work with ;)The update I'd like to propose is to the Zend Highlighter for PHP,
specifically related to the highlight_file and highlight_string
functions, as well as the php -s command.My proposal is a very simple one, which would add a third parameter,
which would be optional, which would select between "inline" styling,
and external styling. The proposed syntax for highlight_file would be:mixed highlight_file (string $filename [, bool $return= false [, bool
$inline= true]]);Currently, syntax highlighting is done inline, by means of the style
attribute of the span tag (<span style="color: #FFFFFF">...</span>). My
proposition would be for a "class" attribute to be set instead of the
style attribute, based on the value of $inline (<span class="phpcomment">...</span>).I have written a quick and easy patch for this [1], which instead of
adding a new parameter to the highlight functions adds 6 new ini
settings:highlight.inline_class (yes I know the name is weird, but thought it
was better than highlight.use_classes or similar)
highlight.class_(comment|default|keyword|html|string)Each of the highlight.class_* sets a default class to use, these are
editable so they won't conflict with class names your style might have
defined to something else, therefore making it more modular. A simple:$ php -d highlight.inline_class=1 -s -f file.php
Will now give:
<span class="xxx"><span class="yyy">...</span></span>Instead of before giving:
<span style="color: xxx"><span style="color: yyy">...</span></span>I thought using ini settings was more in place with how the current
API works so I went that way. The patch isn't perfect but it does its
job, note that its written for PHP_5_3, but since we're in RC stage
theres really no chance of it getting added.The issue this modification is intended to fix is that many developers
who intend to provide syntax highlighting in their project end up
rolling their own code for such. By providing external styling code
rather than inline styling, it makes it possible to modify the style of
all highlighted code, without modifying the code itself. It also
provides the capability to extend the viewing experience with
Javascript, such as code folding functionality.I've taken the liberty to produce a very quick and dirty patch, which is
by no means complete, but provides a cursory example of what I intend.I'd like to clarify that this is the first time I've modified PHP's
code, and I know very little C. The only modifications I've done for PHP
in the past have been in the PHP-GTK branch, attempting to fix the
documentation generator to work with the non-standard extension
structure. If I've submitted my proposal poorly, I apologize.Please offer any comments you have.
Thank you,
Justin Martin aka FrozenFire--
Hi,
The update I'd like to propose is to the Zend Highlighter for PHP,
specifically related to the highlight_file and highlight_string
functions, as well as the php -s command.
I don't see the need for a rush (or in other words: 5.3 can happily live
without it imo) and for the general consideration there's still my patch
from 2005 using a <ol> to have line numbers and adding id's so lines can
directly be accessed by an URL.
http://schlueters.de/~johannes/php/zend_highlight_20050312_1.diff
About ini settings: We should avoid adding them as much as possible,
making this an ini setting gives you trouble in case the admin plays
with them for some reason and you don't overwrite them in the script, on
the other hand it's the only way to make it work with "php -s" and the
apache sapi's application/x-httpd-php-source.
So in summary: Let's think carefully about this before committing the
first idea which comes to mind.
johannes
Hi,
The update I'd like to propose is to the Zend Highlighter for PHP,
specifically related to the highlight_file and highlight_string
functions, as well as the php -s command.I don't see the need for a rush (or in other words: 5.3 can happily
live
without it imo) and for the general consideration there's still my
patch
from 2005 using a <ol> to have line numbers and adding id's so lines
can
directly be accessed by an URL.http://schlueters.de/~johannes/php/zend_highlight_20050312_1.diff
About ini settings: We should avoid adding them as much as possible,
making this an ini setting gives you trouble in case the admin plays
with them for some reason and you don't overwrite them in the
script, on
the other hand it's the only way to make it work with "php -s" and the
apache sapi's application/x-httpd-php-source.So in summary: Let's think carefully about this before committing the
first idea which comes to mind.
+1 .. lets get this sorted out in HEAD. Both the styling and the
optional support for line numbers and anchors.
As for Chris Stockton's proposal for simply having an array parameter
with predefined keys, is this the first time we are starting to feel
the need for named parameters in a real world example of something to
be added to core? I know that several users have proposed such a
feature before, but imho before we start adding arrays as a poor mans
named parameter support, we might want to open that pandoras box
again. Again nothing for 5.3 .. HEAD is where its at.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
2009/4/2 Justin Martin frozenfire@thefrozenfire.com:
Hello everyone,
--
Just as an update, I reviewed my previous patch and re did it (attached).
Instead of adding the highlight.class_* INI entries, this simply adds two:
- highlight.inline_styles (default 1), set to 0 to trigger the use of classes
- highlight.class_prefix (default ""), set to a class prefix of choice
to prevent naming conflicts
I thought adding a class_prefix would be better than adding a yet
another class name on the <code> tag, prefixing should work out just
perfect.
--
Kalle Sommer Nielsen
kalle@php.net
Just a friendly prodding. Was this ever added?
Thanks,
Justin Martin