KConfig list entries vs. kde3 vs. desktop entry spec (Re: list separator in config entries)

[Oswald Buddenhagen]

[another broken off subthread to regain attention]

the basic problem is how KConfig's ini backend is supposed to deal with
list entries.
for clarification, at the lowest level there is a layer of escaping
which encodes control chars and surrounding whitespace as backslash
escapes to support saving arbitrary data as single lines of text.
but then the fun with lists starts. there are basically two approaches:
- make list encoding an additional layer
- weave list encoding into the lowest layer

the 1st approach:
- is used in kde3
- leads to slightly unreadable entries: a list containing only the value
  "foo;bar\" is encoded as "foo\\\;bar\\\\".
- theoretically allows for arbitrarily complex nesting structures.
  purely academical ...

the 2nd approach:
- is suggested by the desktop entry spec
- produces readable entries: a list containing only the value
  "foo;bar\" is encoded as "foo\;bar\\".

1st is architecturally cleaner. it allows doing the lowest-level
decoding independently of what type the entry needs to be converted to
later. however, as it turns out, this is irrelevant for both kconfig
itself and - assuming kconfigXT-ification throughout - even our (still
hypothetical?) config editor.

compatibility considerations ...
regarding 1st vs. the desktop entry spec one could either:
- ignore the problem. currently nothing that would be affected is
  specified. a clarification for changing the spec to 1st could be
  issued when it becomes necessary.
- introduce a "desktop entry mode" into kconfig. obviously only
  necessary if it becomes relevant and modifying the spec is refused by
  other parties.
regarding 2nd vs. kde3:
- of course this means kconf_update-ing a lot.
  auto-conversion is not possible: while the escape \; is not defined in
  kde3 at the lowest encoding layer and thus entries containing \\\;
  could be simply converterd, \\\\ might appear in both singular and
  list entries alike - meaning different things.
  one could semi-automate the creation of update scripts by simply
  grepping kde3 sources for the relevant function calls.
- again, there are those dreaded shared kde3/kde4 configs
  - are they affected? can i have a list of files to check?
  - like with the other problem, one could rewrite the past by modifying
    kde3, too

while at this point i'd actually prefer 1st (i *love* editing rc files
by hand :) i guess the amount of work involved and the resulting risks
are simply prohibitive.
i.e., i should fix kde4 by making it behave like kde3.
thoughts?

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.