[SVN] More name revising

[Allan Odgaard]

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)

Yes.

> 3.    In JavaScript we have event-handlers as well. So should these 
> 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, 
while(true) etc.).

So actually, I'm thinking of this more from a stylistic POV than 
language purism.

> === (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.