I just noticed that the coloration for "def" is a bit overeager, see attached snapshot. Look for "def_port".
Ollivier Robert wrote:
I just noticed that the coloration for "def" is a bit overeager, see attached snapshot. Look for "def_port".
This is not just def in Ruby. It's all highlighting based on keywords. Keywords preceeded by characters works okay, but keywords followed by anything is still highlighted (if there is no other highlighting active).
IMO keywords should only be highlighted if they are not followed by alphanumeric characters or '_'.
Jeroen.
According to Jeroen:
This is not just def in Ruby. It's all highlighting based on keywords. Keywords preceeded by characters works okay, but keywords followed by
OK.
IMO keywords should only be highlighted if they are not followed by alphanumeric characters or '_'.
Could be language dependent but something close to that yes.
While I'm in the Ruby mode, folding works only for def..end pairs, not class..end, module..end or if..then..else..end.
On Oct 14, 2004, at 3:25 AM, Ollivier Robert wrote:
While I'm in the Ruby mode, folding works only for def..end pairs, not class..end, module..end or if..then..else..end.
This is easy to fix, if you want to edit your .plist file. I copied the stock Ruby bundle and modified Ruby.tmbundle/Syntaxes/Ruby.plist so that the "foldingStartMarker" key has the following value:
^\s*(class|module|def)>
That makes class & module be foldable. I didn't add it for "if" and the rest; actually, it looks like you could use most of the regexp in "increaseIndentPattern" for the folding markers.
-- John Labovitz Consulting, LLC http://mac.johnlabovitz.com johnl@johnlabovitz.com AIM/iChat: jslabovitz +1 503.949.3492
On 14. Oct 2004, at 13:19, John Labovitz wrote:
This is easy to fix, if you want to edit your .plist file. I copied the stock Ruby bundle and modified Ruby.tmbundle/Syntaxes/Ruby.plist so that the "foldingStartMarker" key has the following value:
^\s*(class|module|def)>
You may want it to be (showing double escapes here):
^\s*(class|module|def)\>(?!.*\<end\>)";
The (?!...) part is a negative look-ahead assertion and means, that the keywords shouldn't be followed by the pattern (which here is just .*end). So for example a line that has: "def method ... end" will not appear as a fold start marker.
Kind regards Allan
On 14 Oct 2004, at 11:00, Jeroen wrote:
Ollivier Robert wrote:
I just noticed that the coloration for "def" is a bit overeager, see attached snapshot. Look for "def_port".
This is not just def in Ruby. It's all highlighting based on keywords. Keywords preceeded by characters works okay, but keywords followed by anything is still highlighted (if there is no other highlighting active).
I've just done a few tests (in beta 3), and it seems this problem *only* affects the 'def' keyword. I think the cause of this is the following lines in the syntax definition file:
{ name = "Method With Arguments"; match = "^\s*(def)\s*([.a-zA-Z_?!]+)\s*\((.*)\)"; "foregroundColor[1]" = "#CC7833"; "fontStyle[3]" = ( italic ); },
{ name = "Method Without Arguments"; match = "^\s*(def)\s*([.a-zA-Z_?!]+)"; "foregroundColor[1]" = "#CC7833"; },
I think the "\s*" in the match option should be "\s+" after "def" (or the < and > anchors should be used), as there should always be whitespace after def, right?
IMO keywords should only be highlighted if they are not followed by alphanumeric characters or '_'.
This seems to be the existing behaviour to me.
Rich Barton
Rich Barton wrote:
On 14 Oct 2004, at 11:00, Jeroen wrote:
This is not just def in Ruby. It's all highlighting based on keywords. Keywords preceeded by characters works okay, but keywords followed by anything is still highlighted (if there is no other highlighting active).
I've just done a few tests (in beta 3), and it seems this problem *only* affects the 'def' keyword. I think the cause of this is the following lines in the syntax definition file:
My bad. I used my own Python syntax highlight file and there I forgot to add > after the special keyword identifiers....
Continuing in this direction: It seems to me that things that are defined as 'keywords' ought to have a default < and > around them. (I must say that I'm not really a big fan of the plists file for syntax highlighting, they don't really work intuitively and the extra \ for each \ in a regexp really doesn't help either.)
Jeroen.
On 14. Oct 2004, at 13:54, Jeroen wrote:
I must say that I'm not really a big fan of the plists file for syntax highlighting, they don't really work intuitively and the extra \ for each \ in a regexp really doesn't help either.
The extra \ can be avoided if you use e.g. Apple's property list editor.
As for intuitive, what do you suggest instead?
Kind regards Allan
Allan Odgaard wrote:
On 14. Oct 2004, at 13:54, Jeroen wrote:
I must say that I'm not really a big fan of the plists file for syntax highlighting, they don't really work intuitively and the extra \ for each \ in a regexp really doesn't help either.
The extra \ can be avoided if you use e.g. Apple's property list editor.
I'll try that.
As for intuitive, what do you suggest instead?
My grievance is that currently everybody is reinventing the wheel, e.g. with the < and > around keywords and which things should be in a syntax highlight file. It would be nice if there's a template available which has the most common things in a highlight file and with reasonable default values for them. I'll try to look into that this weekend or something.
Jeroen.
-
Allan Odgaard -
Jeroen -
John Labovitz -
Ollivier Robert -
Rich Barton