[SVN] Naming convention

Mats Persson mats at imediatec.co.uk
Sat Apr 23 10:33:02 UTC 2005 

Apologies for the length of this, but there's several worthwhile points 
in here ;-)

On 22 Apr 2005, at 20:36, Allan Odgaard wrote:
> I pruned the list and placed it in the wiki with clarification and 
> examples:
>    http://macromates.com/wiki/pmwiki?n=Main.NamingLanguageElements

Elegantly done, Allan!!  Only a few questions.

1.	Markup languages like <html> or <xml> is described as 
"keyword.markup". Should "markup" not be its own root just like 
"variable" has become ??  Bit uncertain about the logic behind it being 
a keyword.

2.	"Variable" in my world is $variable (in PHP), @variable in Ruby, 
whereas INT_MAX would be a "constant" in my book. I guess I might be 
missing something here ;-)

3.	In the PHP syntax file I use "keyword.construct.php" for ( class, 
function, interface, etc. ) keywords. I assume that's much the same as 
what you call "declaration.*" ??
IF so, should I then change it into two sub groups called:
-- "declaration.class.php"  = ( class, interface, extends, etc )
-- "declaration.function.php"  = ( function, etc ? )
or just rename it "declaration.php" ??  Bit confused ATM.


> I think we should generally try to have as few top-level names as 
> possible, adding to the depth rather than the breadth.

I actually thought of just having "comment" in there rather than 
"comment.line" as that would handle both, and users / settings devs 
could extend it themselves in user / language setting files.


On 22 Apr 2005, at 11:14, Mats Persson clumsily expressed the following:
> 1.	 The main themes being: Bright, Dark & Grey.  I think we should 
> consider themes along these lines:
> Bright vs Dark
> Low vs Hi Contrast.
> Sharp vs Subtle
> Sunny vs Cloudy ( as in ambient room light )
>
> Essentially trying to cater for people with different vision 
> 'problems', and also making things more easy to understand for new 
> comers. A theme named 'Grey' is a bit "what the hell does that mean ?" 
> for me. No offence Allan ;)

The idea behind this point was just not to have a large number of 
individual themes, but rather to have a few theme groups along the 
lines of opposing views (badly worded, but I mean sort of "Bright vs 
Dark").  The way I see it, while having a basic minimal number of 
actual implementation themes like WoB, BoW & Grey (=Low Contrast) is 
considered good, it does not make sense for me to switch between WoB 
and BoW themes when I want to switch theme based on my ambient light 
(Sunny vs Cloudy), which actually would just - in my case - change the 
contrast of the colours used and not drastically going between a white 
and dark backgrounds.

Just like TM has many language bundles - most of which I don't use - I 
thought we could have many Themes in logical groups, which could then 
be disabled - like the bundles - according to the users views on 
things.  Each theme is not a complete set of new settings files, but 
rather a user's personal representation of the underlying settings 
files joined with a default Common/General settings file.


> <themeName> Common  or <themeName> General
> In these Common/General Settings Groups we should define a standard 
> group of items along the lines of the root items of each category 
> group, sort of like this:

If we created a lean default settings file this file could easily be 
duplicated for each theme as well.  There would be an issue with 
extensions by language specific settings files and the colours set 
within there, but that is a problem we will always have in every single 
case anyway even if we have just WoB or BoW themes only.

The way I see things is that we the Bundle devs would create our 
Language specific extension settings file - which is very much a 
one-time job (?) - and then each end-user would change the colours in 
to represent their own views. Maybe it's naive, but I see much of the 
settings work to reach maturity very quickly and from then on there 
would be up to the end user.

Therefore IF we could have a system like this, I think we could cut 
down on confusion and clashes between user settings and dev's changes 
to existing settings files

In TM defaults section in /Lib/AppSupp/TM/ (= non user changeable) :
/Themes/
	|-> White_on_Black/
		|-> General.tmSettings
	|-> More_Themes_Like_This
		|-> With_General.tmSettings_files_in_them

/Settings/
	|-> <Language>.tmSettings
	|-> etc. etc


In  ~/Lib/AppSupp/TM/ (user changeable)
/Settings/
	|-> UserDefined.tmSettings  ( = single config like .plist file which 
indicate chosen Themes, Settings & Language specific overrides in a 
single file)

A Users settings always overrides a dev's default settings. Any new 
setting in a dev's settings file would show up in Users settings. Sort 
of what happens today when you change a Command/Snippet/Macro in a 
bundle. Of course this would require more work from Allan's side, but I 
think the end product would be better.

I hope I make more sense in this post (???) :)  I'm actually trying to 
cut down on the work, possible confusions/clashes while maintaining 
user flexibility and alternatives to fixed GUI settings. Sort of like 
TM has done in so many other areas versus the unmentionable 
competition. ;-)


Kind regards,

Mats

----
"TextMate, coding with an incredible sense of joy and ease"
- www.macromates.com -

More information about the textmate-dev mailing list