Hi,

The Git service currently uses the `uglify-field-name' function to
convert kebab case to camel case in section and variable names.

From git-config(1):

> All the other lines (and the remainder of the line after the section
> header) are recognized as setting variables, in the form name = value
> (or just name, which is a short-hand to say that the variable is the
> boolean “true”). The variable names are case-insensitive, allow only
> alphanumeric characters and -, and must start with an alphabetic
> character.

Hyphens are allowed in section and variable names. It’s just a soft
convention that Git prefers camel case for its variables.

Also from git-config(1):

> Other git-related tools may and do use their own variables. When
> inventing new variables for use in your own tool, make sure their
> names do not conflict with those that are used by Git itself and other
> popular tools, and describe them in your documentation.

[b4] is an example of a git-related tool that uses hyphens in its
[configuration options].

Much as we Schemers may like our kebab case, we shouldn’t set up a
service in a way that makes it impossible to serialize a subset of valid
syntax.

I would submit a patch removing the routine, but I don’t know if/how you
want to handle backwards compatibility for users who are relying on the
hyphen conversion. Personally, I think this warrants a breaking change.

—Liam


[b4] <https://b4.docs.kernel.org/en/latest/index.html>

[configuration options] <https://b4.docs.kernel.org/en/latest/config.html>

On 2024-04-21 22:49, Liam Hupfer wrote:

> Hi,
>
> The Git service currently uses the `uglify-field-name' function to
> convert kebab case to camel case in section and variable names.
>
>>From git-config(1):
>
>> All the other lines (and the remainder of the line after the section
>> header) are recognized as setting variables, in the form name = value
>> (or just name, which is a short-hand to say that the variable is the
>> boolean “true”). The variable names are case-insensitive, allow only
>> alphanumeric characters and -, and must start with an alphabetic
>> character.
>
> Hyphens are allowed in section and variable names. It’s just a soft
> convention that Git prefers camel case for its variables.
>
> Also from git-config(1):
>
>> Other git-related tools may and do use their own variables. When
>> inventing new variables for use in your own tool, make sure their
>> names do not conflict with those that are used by Git itself and other
>> popular tools, and describe them in your documentation.
>
> [b4] is an example of a git-related tool that uses hyphens in its
> [configuration options].
>
> Much as we Schemers may like our kebab case, we shouldn’t set up a
> service in a way that makes it impossible to serialize a subset of valid
> syntax.
>
> I would submit a patch removing the routine, but I don’t know if/how you
> want to handle backwards compatibility for users who are relying on the
> hyphen conversion. Personally, I think this warrants a breaking change.
>
> —Liam
>
>
> [b4] <https://b4.docs.kernel.org/en/latest/index.html>
>
> [configuration options] <https://b4.docs.kernel.org/en/latest/config.html>

Hi Liam!

You are very right.  There were a few threads on this topic, the
conclusion is following: we should use the original case of target
format for symbols and not automagically change it on serialization.

The (gnu home-services ...) modules are actually deprecated, however
we've not finished migration of some service (git, ssh) to (rde home
service).

The migration path would be following:

0. Optionally implement a generic serializer in (rde serializers ...)
https://git.sr.ht/~abcdw/rde/tree/771ac368/src/rde/serializers/

1. Re-implement git home service with a more complete serializer in
(rde home services version-control) module.

2. Update current features to use new service, announce breaking changes
on rde-devel.

3. Deprecate service in home-services.
https://git.sr.ht/~abcdw/rde/tree/771ac368/src/gnu/home-services/emacs.scm#L279

If you could help with that it would be wonderful.  In case you start to
work this task, try to avoid doing the whole migration in one go, do it
in a few small steps. The smaller the chunks the faster it will be to
review and merge ;)

-- 
Best regards,
Andrew Tropin

On 2024-04-22 11:30, Andrew Tropin wrote:

> On 2024-04-21 22:49, Liam Hupfer wrote:
>
>> Hi,
>>
>> The Git service currently uses the `uglify-field-name' function to
>> convert kebab case to camel case in section and variable names.
>>
>>>From git-config(1):
>>
>>> All the other lines (and the remainder of the line after the section
>>> header) are recognized as setting variables, in the form name = value
>>> (or just name, which is a short-hand to say that the variable is the
>>> boolean “true”). The variable names are case-insensitive, allow only
>>> alphanumeric characters and -, and must start with an alphabetic
>>> character.
>>
>> Hyphens are allowed in section and variable names. It’s just a soft
>> convention that Git prefers camel case for its variables.
>>
>> Also from git-config(1):
>>
>>> Other git-related tools may and do use their own variables. When
>>> inventing new variables for use in your own tool, make sure their
>>> names do not conflict with those that are used by Git itself and other
>>> popular tools, and describe them in your documentation.
>>
>> [b4] is an example of a git-related tool that uses hyphens in its
>> [configuration options].
>>
>> Much as we Schemers may like our kebab case, we shouldn’t set up a
>> service in a way that makes it impossible to serialize a subset of valid
>> syntax.
>>
>> I would submit a patch removing the routine, but I don’t know if/how you
>> want to handle backwards compatibility for users who are relying on the
>> hyphen conversion. Personally, I think this warrants a breaking change.
>>
>> —Liam
>>
>>
>> [b4] <https://b4.docs.kernel.org/en/latest/index.html>
>>
>> [configuration options] <https://b4.docs.kernel.org/en/latest/config.html>
>
> Hi Liam!
>
> You are very right.  There were a few threads on this topic, the
> conclusion is following: we should use the original case of target
> format for symbols and not automagically change it on serialization.
>
> The (gnu home-services ...) modules are actually deprecated, however
> we've not finished migration of some service (git, ssh) to (rde home
> service).
>
> The migration path would be following:
>
> 0. Optionally implement a generic serializer in (rde serializers ...)
> https://git.sr.ht/~abcdw/rde/tree/771ac368/src/rde/serializers/
>
> 1. Re-implement git home service with a more complete serializer in
> (rde home services version-control) module.
>
> 2. Update current features to use new service, announce breaking changes
> on rde-devel.
>
> 3. Deprecate service in home-services.
> https://git.sr.ht/~abcdw/rde/tree/771ac368/src/gnu/home-services/emacs.scm#L279
>
> If you could help with that it would be wonderful.  In case you start to
> work this task, try to avoid doing the whole migration in one go, do it
> in a few small steps. The smaller the chunks the faster it will be to
> review and merge ;)

Made a ticket for it, feel free to claim it yours if you start working
on it :)

https://todo.sr.ht/~abcdw/tickets/21

-- 
Best regards,
Andrew Tropin