~abcdw/rde-devel

2 2

INI Serializer

Details
Message ID
<86h6ypbori.fsf@conses.eu>
DKIM signature
pass
Download raw message
Hi Andrew,

On https://lists.sr.ht/~abcdw/rde-devel/patches/35481, you mentioned how
the (gnu home-services-utils) module would be deprecated in the near
feature as the reason why we should not use the
generic-serialize-ini-config and should instead move to
serialize-ini-config.

Upon configuring feature-gtk3 in my system with the applied patches, I
noticed that the current INI serializer isn't as flexible as the
previous one. For one, you can't write your own serialization of the fields
meaning you can't, for instance, camel-case the keys. While with the
current serializer you can manually type the symbols as-is, I don't
understand the reason behind this loss of flexibility.

Another limitation is that if you want to include more than one symbol
in a INI section or value, your only choice is to use strings.
In the case of ini sections, this is not even possible because you can only use
symbols (see
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/serializers/ini.scm#L51).
In the case of values, these get serialized with surrounding double-quotes,
which I don't think is very common in INI files. An example of this
shortcoming happened to me while configuring the gtk-font-name setting
in feature-gtk3. With the previous serializer, this would end up as
something like "Cantarell, 11" (without double-quotes), whereas with the
current one it ends up with double-quotes and isn't correctly parsed by
GTK applications, thus not being applied.

One way to go about this would be using lists instead of strings, but
the INI serializer explicitly warns against this in "INI term should be
a non-list value".

What's your take on this? Should we allow users to define their own
field serializer like before, or should we simply try and amend the
current INI serializer to allow lists in ini sections and values? Do
please let me know if I'm missing something here, this is just what I
was able to gather in my short time testing this.

-- 
Best regards,
conses
Details
Message ID
<86cz9dbon6.fsf@conses.eu>
In-Reply-To
<86h6ypbori.fsf@conses.eu> (view parent)
DKIM signature
pass
Download raw message
I just wanted to note from the previous email that feature-gtk3 is a
personal feature I have in my configuration, but the issues I've been
having are concerned with home-gtk3-service-type.

-- 
Best regards,
conses
Details
Message ID
<87v8muuwjd.fsf@trop.in>
In-Reply-To
<86h6ypbori.fsf@conses.eu> (view parent)
DKIM signature
pass
Download raw message
On 2022-11-23 17:48, conses wrote:

> Hi Andrew,
>
> On https://lists.sr.ht/~abcdw/rde-devel/patches/35481, you mentioned how
> the (gnu home-services-utils) module would be deprecated in the near
> feature as the reason why we should not use the
> generic-serialize-ini-config and should instead move to
> serialize-ini-config.
>
> Upon configuring feature-gtk3 in my system with the applied patches, I
> noticed that the current INI serializer isn't as flexible as the
> previous one. For one, you can't write your own serialization of the fields
> meaning you can't, for instance, camel-case the keys. While with the
> current serializer you can manually type the symbols as-is, I don't
> understand the reason behind this loss of flexibility.

I think we want to be consistent with underlying config casing for
easier mapping from original program documentation to lispy config.

>
> Another limitation is that if you want to include more than one symbol
> in a INI section or value, your only choice is to use strings.
> In the case of ini sections, this is not even possible because you can only use
> symbols (see
> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/serializers/ini.scm#L51).
> In the case of values, these get serialized with surrounding double-quotes,
> which I don't think is very common in INI files. An example of this
> shortcoming happened to me while configuring the gtk-font-name setting
> in feature-gtk3. With the previous serializer, this would end up as
> something like "Cantarell, 11" (without double-quotes), whereas with the
> current one it ends up with double-quotes and isn't correctly parsed by
> GTK applications, thus not being applied.

There is a way to define symbols with whitespaces with:

#{Font With Spaces 11}#

Also the ini serializer supports G-expressions, so you can use:

,#~"Something literraly inserted in config file"

or something like that:

,#~(format #f "~a ~s" "unquoted" "quoted")

>
> One way to go about this would be using lists instead of strings, but
> the INI serializer explicitly warns against this in "INI term should be
> a non-list value".
>
> What's your take on this? Should we allow users to define their own
> field serializer like before, or should we simply try and amend the
> current INI serializer to allow lists in ini sections and values? Do
> please let me know if I'm missing something here, this is just what I
> was able to gather in my short time testing this.

Maybe such approach isn't most flexible, but very consistent and good
enough to cover all use-cases.  Let me know if I missed or didn't answer
something.

-- 
Best regards,
Andrew Tropin
Reply to thread Export thread (mbox)