list separator in config entries

[Andreas Hartmetz]

2007/10/8, Oswald Buddenhagen <ossi at kde.org>:
> On Mon, Oct 08, 2007 at 03:41:35AM +0200, Bernhard Loos wrote:
> > The problem occurs on writing a list like "foo\" "bar".
> > This will lead to "foo\, bar"
> >
> if *this* is true, the ini backend is screwed up already ...
>
> > introduce another bad hack like double escaping backslashes in list
> > entries or something.
> >
> what's a bad hack about this? in principle, list concatenation and value
> writeout are two separate levels:
>
> input => after concat => after ini writeout
> "foo" "bar" => "foo, bar" => "foo, bar"
> "foo\" "bar" => "foo\\, bar" => "foo\\\\, bar"
> "foo," "bar" => "foo\, bar" => "foo\\, bar"
> "foo\," "bar" => "foo\\\, bar" => "foo\\\\\\, bar"
>
> to make things less confusing, one could choose a different escape char
> for the concatenation:
>
> "foo" "bar" => "foo, bar" => "foo, bar"
> "foo\" "bar" => "foo\, bar" => "foo\\, bar"
> "foo," "bar" => "foo^, bar" => "foo^, bar"
> "foo\," "bar" => "foo\^, bar" => "foo\\^, bar"
> "foo^," "bar" => "foo^^, bar" => "foo^^, bar"
>
> note that ideally arbitrary structures could be serialized (e.g., lists
> of structures (which would be represented as lists, too)). but then
> one'd include ( and ) into the set of list construction chars, otherwise
> it would lead to completely unreadable entries.
>
> now comes the desktop entry spec. it says this:
> "The multiple values should be separated by a semicolon. Those keys
> which have several values should have a semicolon as the trailing
> character. Semicolons in these values need to be escaped using \;."
>
> great. obviously, it does not mandate the separation of levels i
> postulated. this essentially means, that separator parsing needs to be
> done at the lowest level. this means that a) more complex structures are
> not possible, b) even the lowest-level api needs to deal with lists
> already and c) either c1) non-list entries have to escape the separator,
> too, or c2) the backend needs to keep raw values in the entry map and
> only parse them when their type becomes knows when the value is
> requested.
>
Everything works fine if you escape the escape char - this is in the
spec IIRC. The parser just needs to be smart enough to recognize '\\;'
as "escaped backslash-semicolon" instead of "oh, there's a \, so let's
parse that and uh, we also have a single backslash in front of  it".