[Geany-devel] Separate color schemes and filetype definitions

[Nick Treleaven]

On Tue, 16 Feb 2010 14:03:48 +0100
"Jonas H." <jonas at lophus.org> wrote:

> I have a suggestion regarding color schemes/filetype definitions.
> 
> Currently, filetype definitions (keywords, compile-commands, ...) and 
> syntax highlighting color schemes aren't separate, it's one file.
> 
> This results in problems:
> 
> 1. if you update filetype defs, there are still lots of old defs going 
> around on the Net (included in custom color schemes)
> 2. if you switch the color scheme, you lose filetype settings 
> (compile-commands, ...)
> 3. creating new color schemes is very time-wasting and annoying, because 
> you will do a lot of copy and paste.
> (to be extended)
> 
> My suggestion is: Separate filetype definitions and color schemes. For 
> example, think of two directories, "colorschemes" and "filedefs". A 
> filedef file contains stuff like a keyword list and so on. A color 
> scheme file contains nothing more but kinda 
> keyword-type-color-assignment, such as
> 
>    primary = #somecolor
> 
> Furthermore I would implement something like inheritance, escpecially 
> for filedefs. Let me explain what I mean by 'inheritance' in that case:
> 
> You have default filedefs in /usr/share/geany/fildefs (or whatever). If 
> a custom filedef is given in .config/geany/filedefs (or whatever), all 
> 'keys' given in that custom file will be overriden. Advantage of this 
> is: The custom files don't have to be a 1:1 copy, but only some kind of 
> 'override-file'.
> 
> Advantage of this is: You can have custom settings for example for 
> compile commands, but still can go with the current up-to-date keyword 
> list (delivered with Geany).
> 
> What do you think?

Ths user filetype files don't have to override everything - IMO it's a
bug in the manual that suggests copying the entire system file. Just
put what you want overridden in there.

You are right about the problem of installing/changing color schemes -
if the file is overwritten then you lose any custom settings like build
commands.

I've been trying to fix this by using a single colorscheme file that
defines 'named styles' (see the manual, ideally dev version). Then
filetype files just say which named style to use for each of their
filetype-specific styles.

This is done for C-like filetypes, but it'd be great if people
working on colorschemes could update some of the other filetype files,
no doubt adding some new named styles also.

Regards,
Nick