[Geany] remembering folding status

[Lex Trotman]

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>