GNU bug report logs - #55606
[PATCH 2/2] gnu: Add hare.

Previous Next

Full log

View this message in rfc822 format

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Antero Mejr <antero <at> mailbox.org>
Cc: 55606 <at> debbugs.gnu.org
Subject: [bug#55606] [PATCH 2/2] gnu: Add hare.
Date: Tue, 24 May 2022 19:10:24 +0200

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

Antero Mejr via Guix-patches via 写道：
> Guix style was indenting badly when applied to the hare package, 
> putting the
> text far past 80 characters. Corrected it by hand.

This caught my attention; I didn't review anything.

Guix style just follows the same rules we should follow.  Don't 
‘fix’ the result unless there's a real bug in ‘guix style’.

Instead, work with it, in this case by adding newlines.  This:

 (proc "foo"
  "bar")

reads *wrong* to humans.

Worse, it's forever a pain to maintain, because nobody can ever 
auto-indent any changes they make to your hand-tweaked code.  They 
have to work around it.

Instead, when necessary, write:

 (proc
  "foo"
  "bar")

> +         (list (string-append "DESTDIR=" (assoc-ref %outputs 
> "out"))

In this case you'd a newline after the above ‘string-append’.

> +               (string-append "HAREC="
> +                              (string-append (assoc-ref 
> %build-inputs "harec")
> +                                             "/bin/harec"))

This is easy to fix: theres no need for the inner string-appends 
in this section.

 (string-append "HAREC="
                (assoc-ref %build-inputs "harec")
                "/bin/harec")

is 100% equivalent.  If the line is still too long, add newlines 
where it keeps the code the clearest.

With such changes, you can run ‘guix style’ (or let your editor 
indent the code) without worries or manual fix-ups.

Kind regards,

T G-R

[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.