[Geany-devel] Separate color schemes and filetype definitions
nick.treleaven at xxxxx
Wed Feb 17 13:07:28 UTC 2010
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
> 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
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
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.
More information about the Devel