[bug#29438] [PATCH 2/2] services: configuration: Show default values of list types.

["Clément Lassieur" <clement@lassieur.org>]

Ludovic Courtès <ludo@gnu.org> writes:

> Clément Lassieur <clement@lassieur.org> skribis:
>
>> * doc/guix.texi (Messaging Services): Regenerate it.
>> * gnu/services/configuration.scm (show-default?): Fix recursion.
>> * gnu/services/messaging.scm (show-default?): Fix recursion.
>
> Rather “Check VAL rather than DEFAULT.”
>
>> (prosody-configuration)[modules-enabled]: Remove default value from docstring.
>
> LGTM, though I’m afraid we’ll have a hard time keep guix.texi in sync,
> at least until we have an automated mechanism to regenerate those bits.

Thank you for reviewing!

It's a bit sad that most services' docstrings are not in sync with the
.texi file, it would be great to have an automated mechanism to update
the documentation.  I use a hackish Emacs snippet to maintain Prosody
documentation, but something like "make generate-documentation
<service>" would be much better.  I'll think about it.

--8<---------------cut here---------------start------------->8---
@c The following documentation was initially generated by
@c (generate-documentation) in (gnu services messaging).  Manually maintained
@c documentation is better, so we shouldn't hesitate to edit below as
@c needed.  However if the change you want to make to this documentation
@c can be done in an automated way, it's probably easier to change
@c (generate-documentation) than to make it below and have to deal with
@c the churn as Prosody updates.
--8<---------------cut here---------------end--------------->8---

I don't really agree with this comment that can be found in several
places in our documentation.  I believe that when there is a
(generate-documentation) procedure, manual edits shouldn't be
encouraged.  But it's probably not worth updating it while there is no
easy way to automatically generate the documentation.

> Also, I was thinking that ‘guix system search’ could display
> field/default-value pairs.  I’m not 100% sure it’s a good idea because
> that could be very verbose.
>
> Thoughts?

It would be verbose indeed, and if people want to have details about
fields and default values, they can search the manual.