GNU bug report logs - #57963
[PATCH 0/1] Support user's fontconfig.

Previous Next

Full log

Message #215 received at 57963 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Tropin <andrew <at> trop.in>
To: Taiju HIGASHI <higashi <at> taiju.info>
Cc: ludo <at> gnu.org, 57963 <at> debbugs.gnu.org,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: Almost plain SXML serializer
Date: Wed, 12 Oct 2022 17:03:27 +0400

[Message part 1 (text/plain, inline)]

On 2022-10-12 20:42, Taiju HIGASHI wrote:

> Andrew Tropin <andrew <at> trop.in> writes:
>
>> On 2022-10-11 06:21, Liliana Marie Prikler wrote:
>>
>>> Am Dienstag, dem 11.10.2022 um 12:54 +0900 schrieb Taiju HIGASHI:
>>>> We can specify invalid value such as (list "foo" '(foo bar) 123).
>>> It will be sanitized before that.
>>>
>>>> > Also, making multi-type fields is debatable, but isn't great IMO.
>>>>
>>>> I see. If we had to choose one or the other, I would prefer the
>>>> string-type field.
>>> Prefer sexp-type.
>>>
>>
>> Current (v5) extra-config has a list type.  This list can contain strings
>> and nested lists, string elements are for raw XML, and list
>> elements are for SXML.
>>
>> This is done I guess to support following use case:
>>
>> (list "<tag>Already existing XML copied from existing .xml file, which
>> we don't want to rewrite to SXML.</tag>"
>>       '((tag (@ (attr1 "value1")
>>                 (attr2 "value2"))
>>              (nested "Part of the configuration defined with SXML")
>>              (empty)))
>>       "<another-tag>Maybe some other part of raw XML</another-tag>")
>>
>> This way we can combine SXML with already existing raw XML.
>>
>> Am I right?
>
> You're right.  The current implementation allows XML string and SXML
> list in the list.  Also, it can mix those.
>

Ok, that means we can cover this use case, but at the same time have
more functionality, clarity and consistency.

We can make extra-config to be SXML only (with G-exps support), this way
we will achieve not only the same functionality, but will get more
advanced features like referencing files/directiories in the /gnu/store
or generating parts of configuration using full-fledged scheme (the
simpliest example is just reading the content of the existing file-like
object or using format to generate "raw XML" and insert it in arbitrary
place of SXML tree).

--8<---------------cut here---------------start------------->8---
(list #~"<tag>Already existing XML copied from existing .xml file, which
we don't want to rewrite to SXML.</tag>"
      `((tag (@ (attr1 "value1")
                (attr2 "value2"))
             (nested "Part of the configuration defined with SXML")
             ,#~(format #f "    <nested-tag>~a</nested-tag>" #$variable)
             (fontdirs
              (dirs ,(file-append font-iosevka "/share/fonts")))
             (empty)))
      #~(call-with-input-file #$(local-file "old.xml") get-string-all)
      #~"<another-tag>Maybe some other part of raw XML</another-tag>")
--8<---------------cut here---------------end--------------->8---

Liliana, Ludo what do you think?

>>>> > If serialization would support G-exps, we could write
>>>> >
>>>> > (list #~"RAW_XML_HERE")
>>>> >
>>>> > or even something like this:
>>>> >
>>>> > (list #~(READ-THE-WHOLE-FILE #$(local-file "our-old.xml")))
>>>>
>>>> Does it mean that the specification does not allow it now? Or does it
>>>> mean that it is not possible with my implementation?
>>> I think your serialize would have to unpack the G-Expressions.  You can
>>> test that with some example configs of your own.
>>>
>>>> >
>>> Cheers
>
> Thanks,

-- 
Best regards,
Andrew Tropin

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.