Xinglu Chen <public@yoctocell.xyz> writes:
> * mail.scm (%isync-all-caps-words): New variable.> (serialize-isync-config): Serialize symbols according to the Isync> naming conventions. Serialize numbers.> ---> The naming of symbols should be consistent across services, one> shouldn’t have to write 'symbol-name in one field and 'SymbolName in> another field. Guix should take care of serializing 'symbol-name to> whatever format the program expects (camelCase, snake_case, etc.).
From one point view it's cool, from another it will force us to cover
all corner cases like SSL, IMAP, etc, as you did below. The problem is
that in some software, potentially, it can be much more difficult than
hardcoding 4 options.
Imagine such example with camel case:
(true-type-font? . true) will produce TrueTypeFont? = True, but it could
be that boolean value must be true in that config format. We can
serialize cars and cdrs differently, but what if the grammar of the
target format is quite complex and we can't be sure if it's a value or
key?
I'm not sure if we really want to play this game with converting cases.
Yes, it does give esthetic look, but for what price.
WDYT?
>> gnu/home-services/mail.scm | 17 ++++++++++++++++-> 1 file changed, 16 insertions(+), 1 deletion(-)>> diff --git a/gnu/home-services/mail.scm b/gnu/home-services/mail.scm> index bfb4284..f3a03c0 100644> --- a/gnu/home-services/mail.scm> +++ b/gnu/home-services/mail.scm> @@ -14,10 +14,25 @@> #:export (home-isync-service-type> home-isync-configuration))> > +(define %isync-all-caps-words> + '("ssl" "imap" "starttls" "imaps"))> +> (define (serialize-isync-config field-name val)> + ;; imap-store => IMAPStore> + ;; user => User> + (define (serialize-symbol symbol)> + (let* ((str (symbol->string symbol)))> + (string-join (map (lambda (word)> + (if (member word %isync-all-caps-words)> + (string-upcase word)> + (string-capitalize word)))> + (string-split str #\-))> + "")))> +> (define (serialize-term term)> (match term> - ((? symbol? e) (symbol->string e))> + ((? symbol? e) (serialize-symbol e))> + ((? number? e) (format #f "~a" e))> ((? string? e) (format #f "~s" e))> (e e)))> (define (serialize-item entry)>> base-commit: 4317b9d171377b51547df3e2cc8dff80f65e47bb
On Fri, Jun 18 2021, Andrew Tropin wrote:
> Xinglu Chen <public@yoctocell.xyz> writes:>>> * mail.scm (%isync-all-caps-words): New variable.>> (serialize-isync-config): Serialize symbols according to the Isync>> naming conventions. Serialize numbers.>> --->> The naming of symbols should be consistent across services, one>> shouldn’t have to write 'symbol-name in one field and 'SymbolName in>> another field. Guix should take care of serializing 'symbol-name to>> whatever format the program expects (camelCase, snake_case, etc.).> From one point view it's cool, from another it will force us to cover> all corner cases like SSL, IMAP, etc, as you did below. The problem is> that in some software, potentially, it can be much more difficult than> hardcoding 4 options.>> Imagine such example with camel case:> (true-type-font? . true) will produce TrueTypeFont? = True,
In this case it would make more sense to use (true-type-font? . #t),
> but it could be that boolean value must be ‘true’ in that config format.
That’s what we have ‘boolean->true-or-false’ in (gnu
home-services-utils) for. :)
> We can serialize cars and cdrs differently, but what if the grammar of> the target format is quite complex and we can't be sure if it's a> value or key?
If the grammar is very complex it just makes more sense to have an
“escape hatch” and let the user provide an opaque string or read from an
extenal file.
In this case, the format of the mbsync file looks pretty well-defined,
mbsync(1) lists all the available options.
> I'm not sure if we really want to play this game with converting cases.> Yes, it does give esthetic look, but for what price.
Most (if not all) of the services that provide Scheme bindings for a
configuration so far have an ‘uglify-field-name’ procedure, or some
equivalent thereof. The same is true for Guix proper, I don’t see why
we should break this convention.
Xinglu Chen <public@yoctocell.xyz> writes:
> On Fri, Jun 18 2021, Andrew Tropin wrote:>>> Xinglu Chen <public@yoctocell.xyz> writes:>>>>> * mail.scm (%isync-all-caps-words): New variable.>>> (serialize-isync-config): Serialize symbols according to the Isync>>> naming conventions. Serialize numbers.>>> --->>> The naming of symbols should be consistent across services, one>>> shouldn’t have to write 'symbol-name in one field and 'SymbolName in>>> another field. Guix should take care of serializing 'symbol-name to>>> whatever format the program expects (camelCase, snake_case, etc.).>> From one point view it's cool, from another it will force us to cover>> all corner cases like SSL, IMAP, etc, as you did below. The problem is>> that in some software, potentially, it can be much more difficult than>> hardcoding 4 options.>>>> Imagine such example with camel case:>> (true-type-font? . true) will produce TrueTypeFont? = True,>> In this case it would make more sense to use (true-type-font? . #t), >>> but it could be that boolean value must be ‘true’ in that config format.>> That’s what we have ‘boolean->true-or-false’ in (gnu> home-services-utils) for. :)>>> We can serialize cars and cdrs differently, but what if the grammar of>> the target format is quite complex and we can't be sure if it's a>> value or key?>> If the grammar is very complex it just makes more sense to have an> “escape hatch” and let the user provide an opaque string or read from an> extenal file.>> In this case, the format of the mbsync file looks pretty well-defined,> mbsync(1) lists all the available options.>>> I'm not sure if we really want to play this game with converting cases.>> Yes, it does give esthetic look, but for what price.>> Most (if not all) of the services that provide Scheme bindings for a> configuration so far have an ‘uglify-field-name’ procedure, or some> equivalent thereof. The same is true for Guix proper, I don’t see why> we should break this convention.
Good points, however
mbsync has well-defined, but not strict grammar. Options are not
case-sensitive, but values is.
I prefer to have my channels be kebab-cased and want to get something like:
MaildirStore work-local
Channel work-inbox
Near ":work-local:inbox"
Far ":work-remote:MY REMOTE INBOX"
Quotes are required, because remote folder has spaces.
Currently I have following configuration:
`((MaildirStore work-local)
,#~""
(Channel work-inbox)
(Near "work-local:inbox")
(Far "work-remote:MY REMOTE INBOX"))
And it maps pretty good to what I get. With proposed patch, it will produce
Maildirstore WorkLocal
Channel WorkInbox
Near ":work-local:inbox"
Far ":work-remote:MY REMOTE INBOX"
Which already maps not so well, what is more important it won't work,
because mbsync work-inbox will fail with:
mbsyncrc:21: unknown store 'work-local'
mbsyncrc:22: unknown store 'work-remote'
So I need to do either:
`((maildir-store work-local)
,#~""
(channel work-inbox)
(near ":WorkLocal:inbox")
(far ":WorkRemote:MY REMOTE INBOX"))
or:
`((maildir-store "work-local")
,#~""
(channel "work-inbox")
(near ":work-local:inbox")
(far ":work-remote:MY REMOTE INBOX"))
And you can see, that we lose original semantics of the grammar and
intoduce additional level of unecessary complexity, so now the user HAS
to know, when the case will be trasformed and when not (symbols vs
strings), which I find confusing already.
We obviously can handle values differently and not to transform the
case for them and the following configuration will start working:
`((MaildirStore work-local)
,#~""
(Channel work-inbox)
(Near "work-local:inbox")
(Far "work-remote:MY REMOTE INBOX"))
But what we really would like to be written by user is:
`((maildir-store work-local)
,#~""
(channel work-inbox)
(near "work-local:inbox")
(far "work-remote:MY REMOTE INBOX"))
Which has the opposite problem, maildir-store will be transformed to
MaildirStore, but work-local will still work-local, which also not very
consistent.
Taking into account all of the stuff mentioned above I still not sure if
we need to do this case-fiddling for mbsync (for other grammars it may
be not the case).
Andrew Tropin <andrew@trop.in> writes:
>> Good points, however>> mbsync has well-defined, but not strict grammar. Options are not> case-sensitive, but values is.>> I prefer to have my channels be kebab-cased and want to get something like:>> MaildirStore work-local>> Channel work-inbox> Near ":work-local:inbox"> Far ":work-remote:MY REMOTE INBOX">> Quotes are required, because remote folder has spaces.> Currently I have following configuration:>> `((MaildirStore work-local)> ,#~"" > (Channel work-inbox)> (Near "work-local:inbox")> (Far "work-remote:MY REMOTE INBOX"))>> And it maps pretty good to what I get. With proposed patch, it will produce>> Maildirstore WorkLocal>> Channel WorkInbox> Near ":work-local:inbox"> Far ":work-remote:MY REMOTE INBOX">> Which already maps not so well, what is more important it won't work,> because mbsync work-inbox will fail with:>> mbsyncrc:21: unknown store 'work-local'> mbsyncrc:22: unknown store 'work-remote'>> So I need to do either:>> `((maildir-store work-local)> ,#~"" > (channel work-inbox)> (near ":WorkLocal:inbox")> (far ":WorkRemote:MY REMOTE INBOX"))>> or:>> `((maildir-store "work-local")> ,#~"" > (channel "work-inbox")> (near ":work-local:inbox")> (far ":work-remote:MY REMOTE INBOX"))>> And you can see, that we lose original semantics of the grammar and> intoduce additional level of unecessary complexity, so now the user HAS> to know, when the case will be trasformed and when not (symbols vs> strings), which I find confusing already.>> We obviously can handle values differently and not to transform the> case for them and the following configuration will start working:> `((MaildirStore work-local)> ,#~"" > (Channel work-inbox)> (Near "work-local:inbox")> (Far "work-remote:MY REMOTE INBOX"))>> But what we really would like to be written by user is:>> `((maildir-store work-local)> ,#~"" > (channel work-inbox)> (near "work-local:inbox")> (far "work-remote:MY REMOTE INBOX"))>> Which has the opposite problem, maildir-store will be transformed to> MaildirStore, but work-local will still work-local, which also not very> consistent.>> Taking into account all of the stuff mentioned above I still not sure if> we need to do this case-fiddling for mbsync (for other grammars it may> be not the case).
WDYT?
On Mon, Jun 21 2021, Andrew Tropin wrote:
> Xinglu Chen <public@yoctocell.xyz> writes:>>> On Fri, Jun 18 2021, Andrew Tropin wrote:>>>>> Xinglu Chen <public@yoctocell.xyz> writes:>>>>>>> * mail.scm (%isync-all-caps-words): New variable.>>>> (serialize-isync-config): Serialize symbols according to the Isync>>>> naming conventions. Serialize numbers.>>>> --->>>> The naming of symbols should be consistent across services, one>>>> shouldn’t have to write 'symbol-name in one field and 'SymbolName in>>>> another field. Guix should take care of serializing 'symbol-name to>>>> whatever format the program expects (camelCase, snake_case, etc.).>>> From one point view it's cool, from another it will force us to cover>>> all corner cases like SSL, IMAP, etc, as you did below. The problem is>>> that in some software, potentially, it can be much more difficult than>>> hardcoding 4 options.>>>>>> Imagine such example with camel case:>>> (true-type-font? . true) will produce TrueTypeFont? = True,>>>> In this case it would make more sense to use (true-type-font? . #t), >>>>> but it could be that boolean value must be ‘true’ in that config format.>>>> That’s what we have ‘boolean->true-or-false’ in (gnu>> home-services-utils) for. :)>>>>> We can serialize cars and cdrs differently, but what if the grammar of>>> the target format is quite complex and we can't be sure if it's a>>> value or key?>>>> If the grammar is very complex it just makes more sense to have an>> “escape hatch” and let the user provide an opaque string or read from an>> extenal file.>>>> In this case, the format of the mbsync file looks pretty well-defined,>> mbsync(1) lists all the available options.>>>>> I'm not sure if we really want to play this game with converting cases.>>> Yes, it does give esthetic look, but for what price.>>>> Most (if not all) of the services that provide Scheme bindings for a>> configuration so far have an ‘uglify-field-name’ procedure, or some>> equivalent thereof. The same is true for Guix proper, I don’t see why>> we should break this convention.>> Good points, however>> mbsync has well-defined, but not strict grammar. Options are not> case-sensitive, but values is.>> I prefer to have my channels be kebab-cased and want to get something like:>> MaildirStore work-local>> Channel work-inbox> Near ":work-local:inbox"> Far ":work-remote:MY REMOTE INBOX">> Quotes are required, because remote folder has spaces.> Currently I have following configuration:>> `((MaildirStore work-local)> ,#~"" > (Channel work-inbox)> (Near "work-local:inbox")> (Far "work-remote:MY REMOTE INBOX"))
I don’t see why one would use symbols for some of the values and strings
for others. Just using strings makes more sense to me.
Also, why would the ‘Far’ field require spaces? Using spaces in
filenames is generally a bad idea anyway.
> And it maps pretty good to what I get. With proposed patch, it will produce>> Maildirstore WorkLocal>> Channel WorkInbox> Near ":work-local:inbox"> Far ":work-remote:MY REMOTE INBOX">> Which already maps not so well, what is more important it won't work,> because mbsync work-inbox will fail with:>> mbsyncrc:21: unknown store 'work-local'> mbsyncrc:22: unknown store 'work-remote'>> So I need to do either:>> `((maildir-store work-local)> ,#~"" > (channel work-inbox)> (near ":WorkLocal:inbox")> (far ":WorkRemote:MY REMOTE INBOX"))>> or:>> `((maildir-store "work-local")> ,#~"" > (channel "work-inbox")> (near ":work-local:inbox")> (far ":work-remote:MY REMOTE INBOX"))>> And you can see, that we lose original semantics of the grammar and> intoduce additional level of unecessary complexity, so now the user HAS> to know, when the case will be trasformed and when not (symbols vs> strings), which I find confusing already.
Simply using strings is simplier and to makes more sense to me, I don’t
see why one would want to mix strings and symbols in the first place.
Mbsync doesn’t treat the value of ‘MaildirStore’ differently than the
value of ‘Far’ or ‘Near’, they are simply strings.
One of the reasons I liked Nix home-manager was that it would configure
most of the things for me (Mbsync, Notmuch, Msmtp), I didn’t have to go
read several man pages just to get a basic working setup.
> We obviously can handle values differently and not to transform the> case for them and the following configuration will start working:> `((MaildirStore work-local)> ,#~"" > (Channel work-inbox)> (Near "work-local:inbox")> (Far "work-remote:MY REMOTE INBOX"))>> But what we really would like to be written by user is:>> `((maildir-store work-local)> ,#~"" > (channel work-inbox)> (near "work-local:inbox")> (far "work-remote:MY REMOTE INBOX"))>> Which has the opposite problem, maildir-store will be transformed to> MaildirStore, but work-local will still work-local, which also not very> consistent.>> Taking into account all of the stuff mentioned above I still not sure if> we need to do this case-fiddling for mbsync (for other grammars it may> be not the case).
We could just serialize the key and value in different ways, like we do
for gitconfig. Since the key and values are separate things, why
wouldn’t we treat them differently.
Xinglu Chen <public@yoctocell.xyz> writes:
> On Mon, Jun 21 2021, Andrew Tropin wrote:>>> Xinglu Chen <public@yoctocell.xyz> writes:>>>>> On Fri, Jun 18 2021, Andrew Tropin wrote:>>>>>>> Xinglu Chen <public@yoctocell.xyz> writes:>>>>>>>>> * mail.scm (%isync-all-caps-words): New variable.>>>>> (serialize-isync-config): Serialize symbols according to the Isync>>>>> naming conventions. Serialize numbers.>>>>> --->>>>> The naming of symbols should be consistent across services, one>>>>> shouldn’t have to write 'symbol-name in one field and 'SymbolName in>>>>> another field. Guix should take care of serializing 'symbol-name to>>>>> whatever format the program expects (camelCase, snake_case, etc.).>>>> From one point view it's cool, from another it will force us to cover>>>> all corner cases like SSL, IMAP, etc, as you did below. The problem is>>>> that in some software, potentially, it can be much more difficult than>>>> hardcoding 4 options.>>>>>>>> Imagine such example with camel case:>>>> (true-type-font? . true) will produce TrueTypeFont? = True,>>>>>> In this case it would make more sense to use (true-type-font? . #t), >>>>>>> but it could be that boolean value must be ‘true’ in that config format.>>>>>> That’s what we have ‘boolean->true-or-false’ in (gnu>>> home-services-utils) for. :)>>>>>>> We can serialize cars and cdrs differently, but what if the grammar of>>>> the target format is quite complex and we can't be sure if it's a>>>> value or key?>>>>>> If the grammar is very complex it just makes more sense to have an>>> “escape hatch” and let the user provide an opaque string or read from an>>> extenal file.>>>>>> In this case, the format of the mbsync file looks pretty well-defined,>>> mbsync(1) lists all the available options.>>>>>>> I'm not sure if we really want to play this game with converting cases.>>>> Yes, it does give esthetic look, but for what price.>>>>>> Most (if not all) of the services that provide Scheme bindings for a>>> configuration so far have an ‘uglify-field-name’ procedure, or some>>> equivalent thereof. The same is true for Guix proper, I don’t see why>>> we should break this convention.>>>> Good points, however>>>> mbsync has well-defined, but not strict grammar. Options are not>> case-sensitive, but values is.>>>> I prefer to have my channels be kebab-cased and want to get something like:>>>> MaildirStore work-local>>>> Channel work-inbox>> Near ":work-local:inbox">> Far ":work-remote:MY REMOTE INBOX">>>> Quotes are required, because remote folder has spaces.>> Currently I have following configuration:>>>> `((MaildirStore work-local)>> ,#~"" >> (Channel work-inbox)>> (Near "work-local:inbox")>> (Far "work-remote:MY REMOTE INBOX"))>> I don’t see why one would use symbols for some of the values and strings> for others. Just using strings makes more sense to me.
Person uses symbols for everything, after that he realizes that one of
remote folders contains spaces and encloses ":work-remote:MY REMOTE
INBOX" into quotes.
>> Also, why would the ‘Far’ field require spaces? Using spaces in> filenames is generally a bad idea anyway.
Despite the good and bad ideas some mail providers uses folders with
spaces.
>>> And it maps pretty good to what I get. With proposed patch, it will produce>>>> Maildirstore WorkLocal>>>> Channel WorkInbox>> Near ":work-local:inbox">> Far ":work-remote:MY REMOTE INBOX">>>> Which already maps not so well, what is more important it won't work,>> because mbsync work-inbox will fail with:>>>> mbsyncrc:21: unknown store 'work-local'>> mbsyncrc:22: unknown store 'work-remote'>>>> So I need to do either:>>>> `((maildir-store work-local)>> ,#~"" >> (channel work-inbox)>> (near ":WorkLocal:inbox")>> (far ":WorkRemote:MY REMOTE INBOX"))>>>> or:>>>> `((maildir-store "work-local")>> ,#~"" >> (channel "work-inbox")>> (near ":work-local:inbox")>> (far ":work-remote:MY REMOTE INBOX"))>>>> And you can see, that we lose original semantics of the grammar and>> intoduce additional level of unecessary complexity, so now the user HAS>> to know, when the case will be trasformed and when not (symbols vs>> strings), which I find confusing already.>> Simply using strings is simplier and to makes more sense to me, I don’t> see why one would want to mix strings and symbols in the first place.> Mbsync doesn’t treat the value of ‘MaildirStore’ differently than the> value of ‘Far’ or ‘Near’, they are simply strings.
Yes, it make sense, but I already mentioned the use case, when the mix
happens very naturally. If we allow to do so => someone will do a will
be very frustrated.
>> One of the reasons I liked Nix home-manager was that it would configure> most of the things for me (Mbsync, Notmuch, Msmtp), I didn’t have to go> read several man pages just to get a basic working setup.>
Service extension mechanism is not capable of sharing values, therefore
Guix Home and Guix System is not as capable as NixOS and home-manager
and won't be able to provide really reasonable default configurations,
because services can't really share all necessary info between each
other. To get a reasonable default configurations in general we need
either rework extension mechanism (See Polymorphic service extension
mechanism) or use some additional tooling on top of Guix Home (like rde
features).
https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E>> We obviously can handle values differently and not to transform the>> case for them and the following configuration will start working:>> `((MaildirStore work-local)>> ,#~"" >> (Channel work-inbox)>> (Near "work-local:inbox")>> (Far "work-remote:MY REMOTE INBOX"))>>>> But what we really would like to be written by user is:>>>> `((maildir-store work-local)>> ,#~"" >> (channel work-inbox)>> (near "work-local:inbox")>> (far "work-remote:MY REMOTE INBOX"))>>>> Which has the opposite problem, maildir-store will be transformed to>> MaildirStore, but work-local will still work-local, which also not very>> consistent.>>>> Taking into account all of the stuff mentioned above I still not sure if>> we need to do this case-fiddling for mbsync (for other grammars it may>> be not the case).>> We could just serialize the key and value in different ways, like we do> for gitconfig. Since the key and values are separate things, why> wouldn’t we treat them differently.
I described just above why we should not serialize symbols differently
for keys and values, but in addition to that we have values list here,
not pairs as in gitconfig, so the difference between symbols is much
more implicit here.
1. We can implement a smaller subset of mbsync config syntax by
forbidding the usage of symbols in values and forcing user to pick
strings instead.
The problem I see here is the inconsistency with other configurations
(Sway for example). It allows to use symbols as values and the case for
them is not transformed.
2. We can make the same way as it done for l2md and create separate
records for Channels, Accounts, Groups, etc. But this approach has its
own downsides: it's more verbose and very sensible to upstream config
changes (adding/removing fields).
3. We can keep the format more open and complete and let user decide how
he wants it to be written. Such approach doesn't have those implicit
case conversions and escapes some other problems, but as a downside
allows a user to fail easier comparing to the second option.
BTW, making more gitconfig like syntax can make some sense here.
`(channel "work-inbox"
((patterns . ("*" "!Spam"))
(near . "work-local:inbox")))
On Mon, Jun 21 2021, Andrew Tropin wrote:
>> I don’t see why one would use symbols for some of the values and strings>> for others. Just using strings makes more sense to me.>> Person uses symbols for everything, after that he realizes that one of> remote folders contains spaces and encloses ":work-remote:MY REMOTE> INBOX" into quotes.
Not sure why one would use symbols for everything to begin with; I
usually just use strings/bool/num for the values.
>>> And it maps pretty good to what I get. With proposed patch, it will produce>>>>>> Maildirstore WorkLocal>>>>>> Channel WorkInbox>>> Near ":work-local:inbox">>> Far ":work-remote:MY REMOTE INBOX">>>>>> Which already maps not so well, what is more important it won't work,>>> because mbsync work-inbox will fail with:>>>>>> mbsyncrc:21: unknown store 'work-local'>>> mbsyncrc:22: unknown store 'work-remote'>>>>>> So I need to do either:>>>>>> `((maildir-store work-local)>>> ,#~"" >>> (channel work-inbox)>>> (near ":WorkLocal:inbox")>>> (far ":WorkRemote:MY REMOTE INBOX"))>>>>>> or:>>>>>> `((maildir-store "work-local")>>> ,#~"" >>> (channel "work-inbox")>>> (near ":work-local:inbox")>>> (far ":work-remote:MY REMOTE INBOX"))>>>>>> And you can see, that we lose original semantics of the grammar and>>> intoduce additional level of unecessary complexity, so now the user HAS>>> to know, when the case will be trasformed and when not (symbols vs>>> strings), which I find confusing already.>>>> Simply using strings is simplier and to makes more sense to me, I don’t>> see why one would want to mix strings and symbols in the first place.>> Mbsync doesn’t treat the value of ‘MaildirStore’ differently than the>> value of ‘Far’ or ‘Near’, they are simply strings.>> Yes, it make sense, but I already mentioned the use case, when the mix> happens very naturally. If we allow to do so => someone will do a will> be very frustrated.
If we allow to do what? I am not able to understand that sentence.
Seeing as people do treat the keys and values differently, people rarely
use stings for the keys, it would only make sense to keep the
serialization of keys and values separate.
>>> We obviously can handle values differently and not to transform the>>> case for them and the following configuration will start working:>>> `((MaildirStore work-local)>>> ,#~"" >>> (Channel work-inbox)>>> (Near "work-local:inbox")>>> (Far "work-remote:MY REMOTE INBOX"))>>>>>> But what we really would like to be written by user is:>>>>>> `((maildir-store work-local)>>> ,#~"" >>> (channel work-inbox)>>> (near "work-local:inbox")>>> (far "work-remote:MY REMOTE INBOX"))>>>>>> Which has the opposite problem, maildir-store will be transformed to>>> MaildirStore, but work-local will still work-local, which also not very>>> consistent.>>>>>> Taking into account all of the stuff mentioned above I still not sure if>>> we need to do this case-fiddling for mbsync (for other grammars it may>>> be not the case).>>>> We could just serialize the key and value in different ways, like we do>> for gitconfig. Since the key and values are separate things, why>> wouldn’t we treat them differently.>> I described just above why we should not serialize symbols differently> for keys and values,
Sorry, I don’t see where you answered that question.
> but in addition to that we have values list here, not pairs as in> gitconfig, so the difference between symbols is much more implicit> here.>> 1. We can implement a smaller subset of mbsync config syntax by> forbidding the usage of symbols in values and forcing user to pick> strings instead.>> The problem I see here is the inconsistency with other configurations> (Sway for example). It allows to use symbols as values and the case for> them is not transformed.
If we just serialized the keys and values differently this wouldn’t be a
problem; serialize the keys to upper camel case, and the values to
strings, as is.
> 2. We can make the same way as it done for l2md and create separate> records for Channels, Accounts, Groups, etc. But this approach has its> own downsides: it's more verbose and very sensible to upstream config> changes (adding/removing fields).>> 3. We can keep the format more open and complete and let user decide how> he wants it to be written. Such approach doesn't have those implicit> case conversions and escapes some other problems, but as a downside> allows a user to fail easier comparing to the second option.>>> BTW, making more gitconfig like syntax can make some sense here.>> `(channel "work-inbox"> ((patterns . ("*" "!Spam"))> (near . "work-local:inbox")))
That would be a good idea since mbsyncrc already defines a kind of hierarchy.
Xinglu Chen <public@yoctocell.xyz> writes:
> On Mon, Jun 21 2021, Andrew Tropin wrote:>>>> I don’t see why one would use symbols for some of the values and strings>>> for others. Just using strings makes more sense to me.>>>> Person uses symbols for everything, after that he realizes that one of>> remote folders contains spaces and encloses ":work-remote:MY REMOTE>> INBOX" into quotes.>> Not sure why one would use symbols for everything to begin with; I> usually just use strings/bool/num for the values.
Take a look at sway configuration for example:
https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/wm.scm#L133
Most of the tokens are presented as symboles and it make a lot of sense.
Actually, even for mbsync it make some sense to use symbols, not strings
as values, because we define identifiers, which later will be used to
reference objects.
Channel work-inbox
Group work
Channel work-inbox
While technically it's possible to use strings here, it still make a lot
of sense to use symbols.
>>>> And it maps pretty good to what I get. With proposed patch, it will produce>>>>>>>> Maildirstore WorkLocal>>>>>>>> Channel WorkInbox>>>> Near ":work-local:inbox">>>> Far ":work-remote:MY REMOTE INBOX">>>>>>>> Which already maps not so well, what is more important it won't work,>>>> because mbsync work-inbox will fail with:>>>>>>>> mbsyncrc:21: unknown store 'work-local'>>>> mbsyncrc:22: unknown store 'work-remote'>>>>>>>> So I need to do either:>>>>>>>> `((maildir-store work-local)>>>> ,#~"" >>>> (channel work-inbox)>>>> (near ":WorkLocal:inbox")>>>> (far ":WorkRemote:MY REMOTE INBOX"))>>>>>>>> or:>>>>>>>> `((maildir-store "work-local")>>>> ,#~"" >>>> (channel "work-inbox")>>>> (near ":work-local:inbox")>>>> (far ":work-remote:MY REMOTE INBOX"))>>>>>>>> And you can see, that we lose original semantics of the grammar and>>>> intoduce additional level of unecessary complexity, so now the user HAS>>>> to know, when the case will be trasformed and when not (symbols vs>>>> strings), which I find confusing already.>>>>>> Simply using strings is simplier and to makes more sense to me, I don’t>>> see why one would want to mix strings and symbols in the first place.>>> Mbsync doesn’t treat the value of ‘MaildirStore’ differently than the>>> value of ‘Far’ or ‘Near’, they are simply strings.>>>> Yes, it make sense, but I already mentioned the use case, when the mix>> happens very naturally. If we allow to do so => someone will do a will>> be very frustrated.>> If we allow to do what? I am not able to understand that sentence.
If we allow to mix strings and symbols as it done in this patch.
> Seeing as people do treat the keys and values differently, people rarely> use stings for the keys, it would only make sense to keep the> serialization of keys and values separate.>>>>> We obviously can handle values differently and not to transform the>>>> case for them and the following configuration will start working:>>>> `((MaildirStore work-local)>>>> ,#~"" >>>> (Channel work-inbox)>>>> (Near "work-local:inbox")>>>> (Far "work-remote:MY REMOTE INBOX"))>>>>>>>> But what we really would like to be written by user is:>>>>>>>> `((maildir-store work-local)>>>> ,#~"" >>>> (channel work-inbox)>>>> (near "work-local:inbox")>>>> (far "work-remote:MY REMOTE INBOX"))>>>>>>>> Which has the opposite problem, maildir-store will be transformed to>>>> MaildirStore, but work-local will still work-local, which also not very>>>> consistent.>>>>>>>> Taking into account all of the stuff mentioned above I still not sure if>>>> we need to do this case-fiddling for mbsync (for other grammars it may>>>> be not the case).>>>>>> We could just serialize the key and value in different ways, like we do>>> for gitconfig. Since the key and values are separate things, why>>> wouldn’t we treat them differently.>>>> I described just above why we should not serialize symbols differently>> for keys and values,>> Sorry, I don’t see where you answered that question.>
With this patch
`((maildir-store work-local)
,#~""
(channel work-inbox)
(near "work-local:inbox")
(far "work-remote:MY REMOTE INBOX"))
produces:
MaildirStore WorkLocal
Channel WorkInbox
Near "work-local:inbox"
Far "work-remote:MY REMOTE INBOX"
which doesn't work.
Converting work-local and work-inbox to WorkLocal and WorkInbox actually
doesn't make sense, because the user have to decide which case should be
used here, so we can make serialization of symbols in keys and values
different, which will allow to get from config above a following result:
MaildirStore work-local
Channel work-inbox
Near "work-local:inbox"
Far "work-remote:MY REMOTE INBOX"
It make some sense, but it can be really confusing, because
(maildir-store work-local) becomes "MaildirStore work-local".
To avoid it symbols must be serialized the same way or symbols for
values have to be banned.
>> but in addition to that we have values list here, not pairs as in>> gitconfig, so the difference between symbols is much more implicit>> here.>>>> 1. We can implement a smaller subset of mbsync config syntax by>> forbidding the usage of symbols in values and forcing user to pick>> strings instead.>>>> The problem I see here is the inconsistency with other configurations>> (Sway for example). It allows to use symbols as values and the case for>> them is not transformed.>> If we just serialized the keys and values differently this wouldn’t be a> problem; serialize the keys to upper camel case, and the values to> strings, as is.
For sway/i3 it's really hard to distinguish between keys and values and
transforming kebab-case to snake case will cause problems for sure.
>> 2. We can make the same way as it done for l2md and create separate>> records for Channels, Accounts, Groups, etc. But this approach has its>> own downsides: it's more verbose and very sensible to upstream config>> changes (adding/removing fields).>>>> 3. We can keep the format more open and complete and let user decide how>> he wants it to be written. Such approach doesn't have those implicit>> case conversions and escapes some other problems, but as a downside>> allows a user to fail easier comparing to the second option.
This is a current format.
>>>>>> BTW, making more gitconfig like syntax can make some sense here.
Let's call this option 4.
>>>> `(channel "work-inbox">> ((patterns . ("*" "!Spam"))>> (near . "work-local:inbox")))>> That would be a good idea since mbsyncrc already defines a kind of hierarchy.
Yep, such style make sense. Sadly, this hierarchy isn't obvious from
isync configuration format.
I'm ok with option 3, because it is simple and humble, doesn't dictate
anything to user and just transfers what he wrote to plain text.
Flexible and very consistent with sway configuration format.
1 is more restrictive, forces user to use strings for values, produces
only a subset of all possible configurations, but this subset is
semantically complete.
But if we provide a more restrictive configuration style, it seems
better to use option 4, which make the hierarchy explicit.
On Tue, Jun 22 2021, Andrew Tropin wrote:
> Xinglu Chen <public@yoctocell.xyz> writes:>>> On Mon, Jun 21 2021, Andrew Tropin wrote:>>>>>> I don’t see why one would use symbols for some of the values and strings>>>> for others. Just using strings makes more sense to me.>>>>>> Person uses symbols for everything, after that he realizes that one of>>> remote folders contains spaces and encloses ":work-remote:MY REMOTE>>> INBOX" into quotes.>>>> Not sure why one would use symbols for everything to begin with; I>> usually just use strings/bool/num for the values.>> Take a look at sway configuration for example:> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/wm.scm#L133> Most of the tokens are presented as symboles and it make a lot of sense.>> Actually, even for mbsync it make some sense to use symbols, not strings> as values, because we define identifiers, which later will be used to> reference objects.>> Channel work-inbox>> Group work> Channel work-inbox>> While technically it's possible to use strings here, it still make a lot> of sense to use symbols.
Ah, that does make some sense.
>>>> We could just serialize the key and value in different ways, like we do>>>> for gitconfig. Since the key and values are separate things, why>>>> wouldn’t we treat them differently.>>>>>> I described just above why we should not serialize symbols differently>>> for keys and values,>>>> Sorry, I don’t see where you answered that question.>>> With this patch>> `((maildir-store work-local)> ,#~"" > (channel work-inbox)> (near "work-local:inbox")> (far "work-remote:MY REMOTE INBOX"))>> produces:>> MaildirStore WorkLocal>> Channel WorkInbox> Near "work-local:inbox"> Far "work-remote:MY REMOTE INBOX">> which doesn't work.>> Converting work-local and work-inbox to WorkLocal and WorkInbox actually> doesn't make sense, because the user have to decide which case should be> used here, so we can make serialization of symbols in keys and values> different, which will allow to get from config above a following result:>> MaildirStore work-local>> Channel work-inbox> Near "work-local:inbox"> Far "work-remote:MY REMOTE INBOX">> It make some sense, but it can be really confusing, because> (maildir-store work-local) becomes "MaildirStore work-local".
This makes sense since the key and value are two separate things, maybe
using pairs instead of tuples would be a better fit?
>>> but in addition to that we have values list here, not pairs as in>>> gitconfig, so the difference between symbols is much more implicit>>> here.>>>>>> 1. We can implement a smaller subset of mbsync config syntax by>>> forbidding the usage of symbols in values and forcing user to pick>>> strings instead.>>>>>> The problem I see here is the inconsistency with other configurations>>> (Sway for example). It allows to use symbols as values and the case for>>> them is not transformed.>>>> If we just serialized the keys and values differently this wouldn’t be a>> problem; serialize the keys to upper camel case, and the values to>> strings, as is.>> For sway/i3 it's really hard to distinguish between keys and values and> transforming kebab-case to snake case will cause problems for sure.
In this case we are talking about mbsync ;)
>>> 2. We can make the same way as it done for l2md and create separate>>> records for Channels, Accounts, Groups, etc. But this approach has its>>> own downsides: it's more verbose and very sensible to upstream config>>> changes (adding/removing fields).>>>>>> 3. We can keep the format more open and complete and let user decide how>>> he wants it to be written. Such approach doesn't have those implicit>>> case conversions and escapes some other problems, but as a downside>>> allows a user to fail easier comparing to the second option.> This is a current format.>>>>>>>>> BTW, making more gitconfig like syntax can make some sense here.> Let's call this option 4.>>>>>> `(channel "work-inbox">>> ((patterns . ("*" "!Spam"))>>> (near . "work-local:inbox")))>>>> That would be a good idea since mbsyncrc already defines a kind of hierarchy.>> Yep, such style make sense. Sadly, this hierarchy isn't obvious from> isync configuration format.>> I'm ok with option 3, because it is simple and humble, doesn't dictate> anything to user and just transfers what he wrote to plain text.> Flexible and very consistent with sway configuration format.>> 1 is more restrictive, forces user to use strings for values, produces> only a subset of all possible configurations, but this subset is> semantically complete.>> But if we provide a more restrictive configuration style, it seems> better to use option 4, which make the hierarchy explicit.
Yeah, I am leaning more towards option 4, which defines a hierarchy and
treats keys and values differently.
Xinglu Chen <public@yoctocell.xyz> writes:
> On Tue, Jun 22 2021, Andrew Tropin wrote:>>> Xinglu Chen <public@yoctocell.xyz> writes:>>>>> On Mon, Jun 21 2021, Andrew Tropin wrote:>>>>>>>> I don’t see why one would use symbols for some of the values and strings>>>>> for others. Just using strings makes more sense to me.>>>>>>>> Person uses symbols for everything, after that he realizes that one of>>>> remote folders contains spaces and encloses ":work-remote:MY REMOTE>>>> INBOX" into quotes.>>>>>> Not sure why one would use symbols for everything to begin with; I>>> usually just use strings/bool/num for the values.>>>> Take a look at sway configuration for example:>> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/wm.scm#L133>> Most of the tokens are presented as symboles and it make a lot of sense.>>>> Actually, even for mbsync it make some sense to use symbols, not strings>> as values, because we define identifiers, which later will be used to>> reference objects.>>>> Channel work-inbox>>>> Group work>> Channel work-inbox>>>> While technically it's possible to use strings here, it still make a lot>> of sense to use symbols.>> Ah, that does make some sense.>>>>>> We could just serialize the key and value in different ways, like we do>>>>> for gitconfig. Since the key and values are separate things, why>>>>> wouldn’t we treat them differently.>>>>>>>> I described just above why we should not serialize symbols differently>>>> for keys and values,>>>>>> Sorry, I don’t see where you answered that question.>>>>> With this patch>>>> `((maildir-store work-local)>> ,#~"" >> (channel work-inbox)>> (near "work-local:inbox")>> (far "work-remote:MY REMOTE INBOX"))>>>> produces:>>>> MaildirStore WorkLocal>>>> Channel WorkInbox>> Near "work-local:inbox">> Far "work-remote:MY REMOTE INBOX">>>> which doesn't work.>>>> Converting work-local and work-inbox to WorkLocal and WorkInbox actually>> doesn't make sense, because the user have to decide which case should be>> used here, so we can make serialization of symbols in keys and values>> different, which will allow to get from config above a following result:>>>> MaildirStore work-local>>>> Channel work-inbox>> Near "work-local:inbox">> Far "work-remote:MY REMOTE INBOX">>>> It make some sense, but it can be really confusing, because>> (maildir-store work-local) becomes "MaildirStore work-local".>> This makes sense since the key and value are two separate things, maybe> using pairs instead of tuples would be a better fit?
Yep, like in option 4.
>>>> but in addition to that we have values list here, not pairs as in>>>> gitconfig, so the difference between symbols is much more implicit>>>> here.>>>>>>>> 1. We can implement a smaller subset of mbsync config syntax by>>>> forbidding the usage of symbols in values and forcing user to pick>>>> strings instead.>>>>>>>> The problem I see here is the inconsistency with other configurations>>>> (Sway for example). It allows to use symbols as values and the case for>>>> them is not transformed.>>>>>> If we just serialized the keys and values differently this wouldn’t be a>>> problem; serialize the keys to upper camel case, and the values to>>> strings, as is.>>>> For sway/i3 it's really hard to distinguish between keys and values and>> transforming kebab-case to snake case will cause problems for sure.>> In this case we are talking about mbsync ;)
I was talking about consistency with other configurations, so it's not
only about mbsync ;)
>>>> 2. We can make the same way as it done for l2md and create separate>>>> records for Channels, Accounts, Groups, etc. But this approach has its>>>> own downsides: it's more verbose and very sensible to upstream config>>>> changes (adding/removing fields).>>>>>>>> 3. We can keep the format more open and complete and let user decide how>>>> he wants it to be written. Such approach doesn't have those implicit>>>> case conversions and escapes some other problems, but as a downside>>>> allows a user to fail easier comparing to the second option.>> This is a current format.>>>>>>>>>>>> BTW, making more gitconfig like syntax can make some sense here.>> Let's call this option 4.>>>>>>>> `(channel "work-inbox">>>> ((patterns . ("*" "!Spam"))>>>> (near . "work-local:inbox")))>>>>>> That would be a good idea since mbsyncrc already defines a kind of hierarchy.>>>> Yep, such style make sense. Sadly, this hierarchy isn't obvious from>> isync configuration format.>>>> I'm ok with option 3, because it is simple and humble, doesn't dictate>> anything to user and just transfers what he wrote to plain text.>> Flexible and very consistent with sway configuration format.>>>> 1 is more restrictive, forces user to use strings for values, produces>> only a subset of all possible configurations, but this subset is>> semantically complete.>>>> But if we provide a more restrictive configuration style, it seems>> better to use option 4, which make the hierarchy explicit.>> Yeah, I am leaning more towards option 4, which defines a hierarchy and> treats keys and values differently.
Yep, probably option 4 make sense. I will keep current serialization as
it is for now and will come back to it later. I need to revisit guix
home service guidlines and move it to manual first.
On Thu, Jun 24 2021, Andrew Tropin wrote:
>> Yeah, I am leaning more towards option 4, which defines a hierarchy and>> treats keys and values differently.>> Yep, probably option 4 make sense. I will keep current serialization as> it is for now and will come back to it later. I need to revisit guix> home service guidlines and move it to manual first.
Yeah, having an official guideline for writing services would be great.
We might also want to add a ‘Migrating to Guix Home’ section in the manual.
Xinglu Chen <public@yoctocell.xyz> writes:
> On Thu, Jun 24 2021, Andrew Tropin wrote:>>>> Yeah, I am leaning more towards option 4, which defines a hierarchy and>>> treats keys and values differently.>>>> Yep, probably option 4 make sense. I will keep current serialization as>> it is for now and will come back to it later. I need to revisit guix>> home service guidlines and move it to manual first.>> Yeah, having an official guideline for writing services would be great.> We might also want to add a ‘Migrating to Guix Home’ section in the manual.
Already on my todo list)