> I would recommend storing new stuff in a new file if a preference file format is insufficient - sort of like language.settings.xml in the .settings
So IIUC you recommend for new code on CDT to *NOT* store settings in
.cproject any longer? Well, I'm fine with that.
+1
> directory. Anything can be stored in the .settings directory, just preferences has a good mechanism.
>
> In addition to what Alexander said, there are three common ways to store in preferences more complicated things:
>
> 1- Single preference with tokens
> 2- Multiple numbered preferences (.e.g pref_0=value0 pref_1=value1 pref_N=2 for an array)
> 3- serialized xml or json
>
> 1 and 3 both are not great for version control as the store lists as a single line making diffs in version control harder than they could be.
Neither is 2): If pref_0=value0 is removed, you will see changes for
pref_1..pref_N in version control instead of just a single deleted
line.
Yes that is a good point. There are a lot of places in Eclipse (CDT and other) that store lists as comma or semi-colon separated on one line (e.g. launch file for enabled plug-ins). These are impossible to read so I really appreciate you taking the time to consider carefully how to store this information.
Concerning 3) serialized xml or json: If it would be stored in
*multiple* lines, it would be more VC friendly. AFAIK, at least Java
property files allow to store multi-line values.
Good point - in practice all the stuff that sticks XML in preferences files today stores the whole XML file in one line (using escaping). I think IMemento interface is used for that.
My guess is that most anything new these days gets stored in a json file. <-- that is not a rule, just an observation
Jonah
Martin
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
