[SVN] More name revising
allan at macromates.com
Thu May 5 13:11:48 UTC 2005
On May 5, 2005, at 10:29, Mats Persson wrote:
>> Move keyword.function to its own group and let this contain all
>> functions, methods, classes, types and constants defined by a
>> framework, library or similar, e.g. (examples from Cocoa): [...]
> 1. Why use "support" here ? In my mind this is not obvious nor
> logical. The items you describe are very much core language items
No, many languages have support libraries. Objective-C is a language,
Cocoa is a framework from Apple. You can use one without the other.
This is true of many languages, and IMHO it does generally make sense
to style the core language stuff differently from what functionality
the support libraries offer.
> 2. "support.constant". Not being a Cocoa developer, I assume that
> NSZeroRect is a language provided constant like E_ERROR in PHP. ie,
> not defined by the user/coder ? (something I've called
> "variable.constant.predefined" previously)
> become "support.event-handler" or "support.other.event-handler" or
> something else ??
hmm... event handlers are special method names that you use in your
code to have them automatically called? So conceptually not very
different from constructors/destructors!?!
I'm not really sure where that belongs. I'd say it's probably more a
keyword than support functionality, since it's not something you
call/use, but a “convention” you conform to.
>> Another group which is also currently a little diffuse is constant, I
>> suggest these 3:
>> constant.numeric -- 42, 1.3f, 0x4AB1U, …
>> constant.character -- <, \e, \031, '"', …
>> constant.language -- true, false, nil, YES, NO, …
> "constant.language" & "support.constant". All these various constants
> have me confused, and I hope I'm not alone in that. (slight repetition
> of point asked above)
> 4. In my mind a Constant can be two things. Predefined or User
> defined. If it's predefined then it's really a key part of the code
> language otherwise it's only a part of the user's code. Either way
> they are really both the same in the end as they are storage
> containers of data just like variables are.
Well, this again is probably about how much is core language, and how
much is add-on.
Constant.language would be for stuff like true, false, YES, NO, nil,
NULL etc. Which I perceive as core-language. Where support.constant is
for a constant like ENT_QUOTES.
Basically, if I have: “return YES;’ I'd prefer not to have both return
and YES styled the same. Similarly, if I do: “var == YES ? NSZeroRect :
NSMakeRect(0, 0, 100, 100);” I don't think that YES and NSZeroRect
should be styled the same. So that's my motivation for placing these 3
things in different base groups. Whereas it's okay with me that
NSZeroRect and NSMakeRect are styled the same, because they are both
Cocoa framework support stuff.
> With that in mind, I see this as more logical:
> -- "keyword.constant" === TRUE, FALSE, NULL, nil, etc, etc.--
> "support.constant" or "lang.constant"
I don't want them under keyword mainly because with only one style for
keyword, too much is suddenly a keyword, and often these language
constants and language keywords are side-by-side (return nil,
So actually, I'm thinking of this more from a stylistic POV than
> === (predefined language constants, like E_ERROR, or NSZeroRect )
> -- "variable.constant" === user defined constants like
> MY_CONSTANT_IN_PHP if the language supports them and they can be
> regexp'ed into usable form.
IMHO a variable is not a constant, it's the opposite. E.g. if you have
“sin(x * PI)” then x is the variable and PI is the constant (sin being
support.function). A number is also a constant (in my book), the same
goes for color definitions, character entities and so on.
I assume that E_ERROR refers to the last error? so this is actually a
variable (since it is not constant).
> This structure would give the end user the best options to choose
> from/work with.
> -- If you want minimal highlighting, then you would choose the
> "Minimal" theme. -- If you want more detailed highlighting, then you
> would choose the default Theme.-- If you want language specific parts
> highlighted on top of your chosen theme, then you would enable the
> Language theme for the language you're working with.
> I really think the above is the right and only way forward. There are
> of course some further issues to address in relation to this, but
> that's for another day.
The default themes will be language neutral, and as of such, all
languages should work adequately with these. How detailed they become I
think is just a matter of what's required to make it look good. I don't
see it as a goal to suit everybodys need with regard to themes, only to
allow people to make for themselves what they want -- my prediction is
that with 3 themes (white, black and grey (as in the simple theme)),
95% of users will just pick the one they like best and stick with it.
More information about the textmate-dev