This is a long post for a simple solution, but I prefer to provide a good background.
I admit - I have a special interest in PHP, but the problem is common to other languages in which an opening tag (<? in PHP's case) is required before coding in that language. Examples are asp, jsp, and possibly XML variants. Problem Definition: In a regular editors like jEdit, the whole file is held in the editing area and getting colored. Therefore, for tagged languages, the colorizer is looking for the language's opening tag before starting to color the code. Text preceding the opening tag is not part of the code and is handled in some commonly accepted manner, e.g. the PHP processor will emit this text as if "echo"ed or printed (typically it is HTML, but not necessarily). Leo is coloring on a per node basis. This means that it is unrealistic to expect a language's opening tag in every node of a file. Typically the opening tag will only be present in the file's root node or in it's first child. This breaks the colorizer's logic, causing the colorizers to fail to color language code in most nodes. Failed or Discouraged Approaches: - Adding @language in every node - does not work for the obvious reason stated above. This only tells Leo what it already knows. - Adding an opening tag in every node - this is "incorrect" for the language stand point. - Out smarting the colorizer by adding a commented starting tag (e.g. //<? for PHP) - this works but clutters the public code unnecessarily. Observations: After examining the coloring rules files in the modes directory, I realized the Leo must be starting the coloring using the rulesDict named <language>_main. This was verified looking at nameToRulesetName (). For PHP, the starting rulesDict is php_main, which is mapped to rulesDict1. rulesDict1 is scanning for an opening tag, and following that switches to rulesDict php_php, which is mapped to rulesDict4. php_php, or rulesDict4 is the one that is actually coloring PHP. I did a simple experiment and edited the file php.py in modes to have php_main map to rulesDict4. The idea is to make the colorizer behave as if it has already found an opening tag and should now color according to the proper PHP coloring rules. This proved successful and effective. Given the problem definition, it becomes very logical. However, this is not THE desired solution because the files in modes are automatically generated from jEdit's XML files and hand editing them is undesired. Proposed Solution: nameToRulesetName() is the function that assumes that the starting coloring rule is <language>_main. I suggest making this user customizable in leoSettings, where one can define languages for which to override this and can give the overriding starting rule. Therefore, in leoSettings (or if needed in myLeoSettings) I could have "php": "php_php" and the php_php rulesDict shall be the starting rulesDict for PHP. This requires very little code change and I believe solves the root cause. 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.
