[...]
Sorry, I was unclear. I was referring to the point above, the ability to edit filetype config files from within geany, with transparent copy to the user config dir if not yet existing: To create a new filetype, it is clearly good practice to copy from an existing one. Instead of explicitely copying from the system-wide config files, as we do now, using the above feature we could just open the existing filetype config file inside geany, and save it under the proper name for the new filetype. (The only issue beeing the difference in naming scheme for custom filetypes, evoked below, but that's independent.)
Well, it isn't *that* hard to open the system config file and save-as in the user config directory, you shouldn't be doing it that often, edit your build commands in the GUI and now stop fiddling with the colours and get on with your work :-D
Thats why its not a high priority.
[...]
- no tweaking of filetype_extensions.conf
Filetype extensions should be declared in the filetype config file.
You find the config file by looking up the language name in filetype_extensions.conf. Geany does *not* read all the language definition files, only the ones needed for open files.
Actually, all the config for a filetype should be in a single file. I first thought there could be no filetype_extensions.conf at all, but this may force geany to read all filetype confg files at startup. Instead, there could a generated one, updated when filetype config files are edited in geany, or whenever geany detects a modif (by last edition time), or via the menu entry "Tools/Reload Configuration".
This would still require Geany to look at all the config files to see which ones had changed, ok its stating it not loading it, but you would have to keep doing it.
Is it a big deal at startup to review the time stamps of files filetypes.* in ~/.config/geany/filedefs, and extract an "extension=*.x" line for the ones having changed? (I'm really asking, not making bad spirit.)
Geany is used in lots of situations, including a number where home directories are on network shares, not local drives. So checking the modification dates of a lot of files is also likely to be slower than on local drives. Geany already does quite a lot on startup it doesn't seem worth it to slow it down to check for something that isn't going to change much and for no benefit to most users.
Since I'm learning Go, I may find the time to do it as an exercise, i have not yet touched the os or fs packages ;-) (You would just have to translate back the routine to C or c++ --I don't even know in what lang geany is coded!)
POC, plain old C
- config file doc
Comments in config files may be rewtritten (they have improved, but still..).
Patches are welcome :)
Some param names can be clearer. (Naming is doc.)
Provide suggestions, being aware that backward compatibility needs to be kept as much as possible.
In fact on further reflection I will make this stronger, there is no way we can change existing names because of the backward compatibility issues without far too much effort.
You know, I have stopped to do that for a while already, because it is depressive experience to do sincere and durable efforts for the common good (after such suggestions as yours) and never see your work into the product, or 1% of it, or 3 years later. Guess you see what I mean...
That happens, Geany is pretty slow to incorporate patches, we only have a small team, all volunteers, and they have other things they want to do, and some even have lives.
Reason why I love wikis. Geany's doc could be a wiki --not only additional texts such as your guide for the build menu. But it's only me, indeed.
The help can't be a wiki since it has to be distributed with Geany, it isn't reasonable to require a network connection to get the manual from help.
Cheers Lex