Hi,
As you say folding isn't fatal (Geany has a unfold all command as fallback) so if the world can accept an occasional dud fold then its much easier.
I didn't think saving the folding in the geany.conf was a good idea because of the potential size increase and the increase in the number of times its read and written all makes for more chances for things to go wrong in a critical file. Instead maybe a geany.folding file in the same directory, then if its broken it can just be deleted.
The g_key_file format that Geany uses does allow for lists but I'm not sure how long they can be, the documentation suggests one line, but I'm sure I have seen lines continued with . But the number of sections and the number of keys is unconstrained, so, if the folding data is in a separate file, then you can have a group per file and a key per folded fold, no need to remember expanded ones thats the default.
e.g.
[file_0] filename=/home/geany/projects/geany/src/folding.c fold_123=true fold_234=true [file_1] filename=xyz.py fold_12=true
The palaver with groups named file_n is because g_key_file does not allow UTF-8 for groups or keys, only ASCII. But key values can be UTF-8 so the filenames must be values not group or key names. The number in the key is the line number, that makes each key in the group different Having the true is redundant but it allows saving the expanded fold points as false if some need arises.
Now it just needs someone to implement it :-)
Cheers Lex
PS <utopia> You are not thinking utopian enough, I want a standard interface between editors and compilers/interpretors so that:the compiler can be run in background and interfaced to by the editor for structure, syntax, completions etc, after all, while I'm editing, those extra cores are just twiddling their electronic thumbs, so lets make them work running the compiler in parallel. Then:
- the editor understands the language as well as the compiler does, including things defined in header files, template instantiations etc. - completions can be only what is legal at that point in the language - the same for function declaration tooltips - *subtle* error indicators can be available immediately (eg margin marks with tooltip messages) - compilation is complete by the time I've saved the file - and the linker, running on another core, is complete too - no need to define languages in the editor, any language with a compiler with this interface is immediately defined
Maybe if Enrico & Nick talked to the GCC guys :-D
</utopia>