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 <frozenf...@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 >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > [1] http://www.paste2.org/p/176166 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
