bug#56297: Guix style imperfections

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> "guix style" occasionally makes some decision that seem a bit
> questionable to me.

Let’s keep in mind that some are bugs/limitations that can be fixed,
while others cannot really be addressed because our tastes vary
depending on context and the pretty printer could hardly be made smart
enough to distinguish all the subtleties.

>> (define-public guile-next
>>  (let ((version "3.0.7") (revision "0")
>>        (commit "d70c1dbebf9ac0fd45af4578c23983ec4a7da535"))
>
> Conventionally 'revision' is put on another line -- for these kind of let bindings,
> (maybe all?), I would recommend to put all of them on separate lines.

This one is a bug IMO: ‘let’ bindings should be treated specially, and
currently they’re not.

>>       (substitute-keyword-arguments (package-arguments guile-3.0)
>>         ((#:phases phases
>>           '%standard-phases) `(modify-phases ,phases
>
> Put %standard-phases on the same line ad #:phases phases and `(modify-phases ,phases
> on a new lineg 

OK.

>>                                 (add-before 'check 'skip-failing-tests
>>                                   (lambda _
>>                                     (substitute* "test-suite/standalone/test-out-of-memory"
>>                                       (("!#") "!#
>>
>>(exit 77)
>>"))
>
> I'd prefer the original "!#\n\n(exit 77)\n" here, but I don't know if that's
> something 'Guix style' could feasibly do (there might be situations where a
> newline might be appropriate, how could "guix style" which is the case?).

Exactly: in synopses/descriptions, we do want to print newlines as-is
(see ‘tests/style.scm’).

Perhaps we could come up with heuristics that make different choices
depending on context, but that sounds tricky.

>>                                     (delete-file
>>                                      "test-suite/tests/version.test") #t))))))
>
> (Would be nice if "guix style" could be taught to remove those #t, but that seems
> more a feature limitation than a bug to me.)

That could be the job of a different style rule (the ‘-S’ option).

>>      (native-inputs (modify-inputs (package-native-inputs guile-3.0)
>>                       (prepend autoconf
>>                                automake
>>                                libtool
>>                                flex
>>                                gnu-gettext
>>                                texinfo
>>                                gperf)))
>
> I'd consider it tidier to put (modify-inputs ...) on a new line

Dunno it’s a matter of taste.  :-)

Ludo’.