<br><br><div><span class="gmail_quote">On 10/13/07, <b class="gmail_sendername">Thomas Braxton</b> <<a href="mailto:kde.braxton@gmail.com">kde.braxton@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><br><div><span class="q"><span class="gmail_quote">On 10/13/07, <b class="gmail_sendername">Oswald Buddenhagen</b> <<a href="mailto:ossi@kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

ossi@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

On Sat, Oct 13, 2007 at 09:52:25AM -0500, Thomas Braxton wrote:<br>> On 10/12/07, Oswald Buddenhagen <<a href="mailto:ossi@kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ossi@kde.org

</a>> wrote:<br>> > the escaping you chose is ... uhm ... ugly. i mean, even uglier than

> > just tree backslashes in a row. > > yeah, but 3 backslashes in a row doesn't work, \x5c does > i think you *really* should re-read my first contribution to this thread and everything that followed from it.

<br><br>> > anyway, a lot of the code looks suspicious, to say the least. i'll<br>> > know more when i actually get my hands on it.<br>><br>> like what?<br>><br>like all the special casing related to lists and separators. it's just

<br>plain weird. why don't you simply use a "forward parser" like<br>KConfigIniBackend::parseConfig() does instead of doing this incredible<br>magic?<br>i'm sure there is more. weirdness doesn't come alone. ;)

</blockquote><div><br> </div></span><div>Ok, give me a day or two. ;) even though this'll probably end up in KConfigIniBackend later anyway.</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>

Ok, here you go. Personally I think this is uglier than hex encoding the trailing backslash. Since we can't know if this is a trailing backslash or escaping the separator, every backslash has to be escaped twice. Once by KConfigGroup, and once by KConfigIniBackend. And I'm not sure, but I think this will cause problems if/when we change KEntry to use QVariant instead of QByteArray, because there's no way for KConfigIniBackend to know if it should unescape the backslashes once or twice.

</div></div><div><br class="webkit-block-placeholder"></div><div>This is how share/config/kconfigtest changes.</div><div><br class="webkit-block-placeholder"></div><div>--- kconfigtest.old<span class="Apple-tab-span" style="white-space:pre">

        </span>2007-10-15 11:29:34.000000000 -0500</div><div>+++ kconfigtest.new<span class="Apple-tab-span" style="white-space:pre">       </span>2007-10-15 11:29:44.000000000 -0500</div><div>@@ -30,9 +30,9 @@</div><div> listOfIntsEntry1=1,2,3,4

</div><div> stringListEmptyEntry=</div><div> stringListEntry=Hello\\,, World</div><div>-stringListEscapeCommaEntry=Hel\\\\\\\\,\\\\\\,\\\\,\\\\\\\\\\,lo,World</div><div>-stringListEscapeEvenEntry=Hello\\\\\\\\x5c,World</div>

<div>-stringListEscapeOddEntry=Hello\\\\\\x5c,World</div><div>+stringListEscapeCommaEntry=Hel\\\\\\\\\\\\\\,\\\\\\\\\\,\\\\\\,\\\\\\\\\\\\\\\\\\,lo,World</div><div>+stringListEscapeEvenEntry=Hello\\\\\\\\\\\\\\\\,World</div>

<div>+stringListEscapeOddEntry=Hello\\\\\\\\\\\\,World</div><div> variantListEntry=true,false,joe,10023</div><div> </div>