> 2. Make the required changes to php.py. I'll add comments to both > php.py and php.xml.txt to make it clear that php.py is the one and > only primary file involved. > > This scheme is clear, flexible and generalizable.
While I did came up with this solution, there is one drawback to this that I need to stress. Overriding the rulesDict of php_main (from rulesDict1 to rulesDict4) means that for text/code following a closing PHP tag (?>), e.g. HTML, the colorizer WILL still attempt to color it as if it is PHP, unless the Leo user will put a specific @language directive following the closing PHP tag. A common PHP practice is something like this (silly example): <?php echo 'hello'; ?> <a href=''>world</a> <?php echo '.'; ?> Preferably, we should not force a change to the (correct) coloring rules of PHP. Instead we just need to have the colorizer start with a better set of the existing rules (php_php instead of php_main) when it starts coloring a node. Gil
-- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
