GNOME Bugzilla – Bug 111060
Add php language support to gtksourceview
Last modified: 2006-05-10 06:32:08 UTC
The following patches add php4 support to gtksourceview
Created attachment 15820 [details] php .lang file
Created attachment 15821 [details] [review] Makefile.am changes
paolo, is this ok to commit?
hmm... I don't like too much the tag names you have used, i.e. "keyword 1", "keyword 2", etc. Are all of them real keyword? Some of them look like function names. IMO, they should be divided into set like "Array function", "Database function" and so on. In this way you can potentially use different styles for different sets. Note that there is a Function style too. I'm attaching here a snorp's .lang file matching Gtk, Bonobo, Gnome functions. I think you could get some good idea on how to write your .lang file from there.
Created attachment 15827 [details] snorp's modified c.lang files
yeah, those are all functions. I just copied the function list from vim php syntax file and broke them up into smaller groups as work-around to bug 110991. There are about 2500 functions defined in php that I have copied from the vim syntax file, how would you recommend I break them up?
the attached file is a php.land, it's not based on a list of function but on the opposite (what is not a function..) su function remains in black and all the rest is colored.. (like in c.lang) at the end you'll find a possible syntax for the "function finder".. it's usable but it will override the keyword if you place them like: if ( $foobar or ( $foo and $bar )) in this case `if` and `or` will be seen as 'functions' and non as 'keyword' the perfection would be to establish a rule of that type: "a function is a function if the functionname is not equal to 'and, or, not, xor' in thet case it's a keyword (operator to be exact)" <pattern-item name = "Open Function Call" style = "Function"> <regex>[a-zA-Z0-9_]+[ ]?(</regex> </pattern-item> the above regex matches "mysql_query(" but even "and (" if it's solvable in a regex [don't know] then we are done :o) even functions declared in the source "function something ($parameter)" will be matched as the syntax dosn't change :oD remember to uncomment the last part of the .lang file if you want to use the function-finder!
Created attachment 16393 [details] a php.lang file for gtksourceview (experimental)
uhmm.. i think it's better as plaintext instead of xml.. (sorry.. the file is the same..)
Created attachment 16394 [details] php.lang (mime: text/plain)
php.lang: after some testing i think that this is preatty stable now..
Created attachment 16532 [details] php.lang
Updated to gtksourceview 0.2.1. Initial support for PHP5
Created attachment 16701 [details] php.lang (gtksourceview 0.2.1)
Thanks for working on this. Some comments on the last version: - Please use " and ' for the pattern definitions - I'm afraid the keywords being highlighted as functions problem currently doesn't have a solution since the engine prioritizes the longest match, which is of course always the function as it has at least one more character. Maybe we could add some priority field, or prioritize keyword lists over pattern items (but I'm afraid something else will break this way). - In the function matching pattern, I think the number of spaces after the name (and before the opening parenthesis) can be more than one, so the repetition operator should be * instead of ? - What does the "Other Keyword" pattern match? - "Data Type" is still in GNU syntax and not Extended POSIX. Also, please use a keyword list to define it. - In general, too much is highlighted IMHO, and it feels a bit heavy on the eyes. But that's a matter of opinions I guess.
> " ' fixed :o) > priority field, i don't have ideas of what will it broke so i'll simply trust your words.. > repetition operator should be * instead of ? it was a workaround for the function|keyword problem i've haven't noticed it when i've placed it online another hack was 'text/html' in the mime part.. ..both fixed :o) > - What does the "Other Keyword" pattern match? $a = $b += $c and other, see http://www.php.net/manual/en/language.operators.php for the complete list.. > "Data Type" is still in GNU syntax and not Extended POSIX. > Also, please use a keyword list to define it. fixed, i'll have to double check every time from now on.. :o) > In general, too much is highlighted IMHO, and it feels a bit heavy > on the eyes. But that's a matter of opinions I guess. Yes.. the php.lang highlight a lot of text compared to C (just numerical vars aren't hilined..) personaly i feel confortable that way but i'll include a modified php.lang called php-light.lang (taken out: "DQ String" "SQ String" "Open Function" "Close Function" "Other Keyword") than we can wait for feedback :o) seeyou! :o) also note: the php-light.lang is mergeable with the Ahmad Baitalmal's php.lang (gnome-devtools) and/or with the html.lang
Created attachment 16861 [details] php-tough.lang (a lot of text hilined)
Created attachment 16862 [details] php-light.lang (less text hilined)
i've made a screenshot with both version of the php.lang file in use if it can be usefull.. http://jaramir.wirewolf.org/~jaramir/gedit3.png the light version is the one on the right, the font is "Bitstream Vera Sans 10" and :o)
Created attachment 20870 [details] Antonio Ognio's version of php.lang featuing support for almost all the built-in constants in PHP
Moving to GNOMEVER2.5 . Is this ready to be commited yet?
I think that we should commit Francesco Gigli's work ASAP and leave the bug open in case any improvments are too be made in the future.
I've just committed the php-light version from Francesco Gigli. I chose that because it provides a good balance in the highlighted text, plus is a small file, and thus easier to maintain. But, since I don't know much PHP and there were other proposed specs, I'm leaving this bug open for a couple of weeks, as suggested by Mark.If you have further suggestions to improve the committed lang file, please add comments. Thanks a lot to all the people who have contributed.
> section="Sources" probably "Scripts" is better as it is an interpreted language
Don't forget that PHP is often embedded into (X)HTML. The current language file makes this a pain, because every HTML part (but the first) is treated as a comment (all green, ugh). I have made the following changes to make it work better for me: - Added the parts from the XML language file to detect tags and attributes (made both same type so it looks less busy and can more easily be distinguished from the PHP parts) - Slightly changed the closing tag regex to also find '/>' which is necessary for XHTML (I'd also suggest this change for the XML language file but I'm no XML expert) - Added HTML style comments, DTD and entities - Commented out regular operators because their is too much ambiguity ('>' could be "greater than" or HTML close tag for example), unless PHP and HTML sections can be separated - Added '->' and '=>' operators so they aren't highlighted as HTML closing tags - Commented out the data types because I don't believe they exist? Please correct me if I'm wrong here. Added 'array' and 'unset' to keyword list instead, because they are built-in functions. So, I like this a lot better and I hope it's useful. However, it obviously has the problem that PHP syntax will be highlighted in HTML code and the other way around. It would be ideal if it would be possible to say that certain rules should only apply to the PHP blocks or non-PHP blocks. But unless that's possible, I believe that this is a good compromise.
Created attachment 26502 [details] Includes HTML style highlighting and other changes
Gustavo: may you give a look at this patch?
I think this is kind of a lost cause until we have the new engine in-place, which will be able to distinguish contexts. Until then, and for the problems Daniel mentions in his last paragraph, I wouldn't apply it. Then again, I don't code PHP in a daily basis and this might be a required feature. So in conclusion, I'd wait for the new engine and fix these issues in a more elegant and correct way.
I'm closing this bug since as Gustavo said we will be able to fix it only when the new engine will be released.
This is broken. This php.lang file above corrects the issues in the latest version.