unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: RFC: new syntax for inline patches
Date: Thu, 06 Jan 2022 08:12:03 +0100	[thread overview]
Message-ID: <87leztba9k.fsf@elephly.net> (raw)
In-Reply-To: <91c6c25534e422d893a3dd219633a2e7ff3f1a68.camel@gmail.com>


Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Donnerstag, dem 06.01.2022 um 02:20 +0100 schrieb Jelle Licht:
>> > 
>> > 
>> > > Here’s a colour sample for the new bikeshed:
>> > > 
>> > >   (arguments
>> > >     (list
>> > >       #:patches
>> > >       #~(patch "the-file"
>> > >          ((line 10)
>> > >           (+ "I ONLY WANTED TO ADD THIS LINE"))
>> > >          ((line 3010)
>> > >           (- "maybe that’s better")
>> > >           (+ (string-append #$guix " is better"))
>> > >           (+ "but what do you think?")))))
>> > Now this thing is again just as brittle as the patch it encodes and
>> > if I know something about context-less patches then it's that
>> > they're super not trustworthy.
>> 
>> What do you mean here, with 'brittle' and 'trustworthy'? Is it the
>> fact that line numbers are hardcoded, compared to the substitute*
>> approach?
> What Ricardo is writing here as a colour sample is a context-less diff
> and if you've ever worked with those, then you'll know they apply
> exactly without context.  So that line 10 is stuck there, it doesn't
> move with regards to whatever entity is interesting at line 10.  The
> second hunk is better in that it needs a line to match and replace, but
> it throws an error if it doesn't find that at line 3010, even if it'd
> exist and 3020 or 2048.

Yes, this example is context-less.  But you know what it’s like looking
at bikeshed colours on a screen: they just don’t pop right, and
dependent on screen calibration or lack thereof they can seem outright
hideous — nothing like the real thing.

So lets take a step back and look at the location and shape of the
bikeshed rather than its color.  Do we agree that it would be lovely to
have a less flexible but declarative pattern to describe changes to
files?  Less flexible than a full-blown editing DSL as that of Emacs,
less flexible than perhaps arbitrary regular expression replacements as
provided by substitute*?  I just think that sometimes we want to focus
on the change itself and not how we get there.

It’s primarily a matter of style and readability.  I think it’s
regrettable to have all these boilerplate build phase shenanigans to
express a simple change in a file.  A large chunk of that is just boring
set up work to be permitted to use “substitute*”, and then the
“substitute*” itself is primarily concerned with an anchor that could
not be much uglier: a regular expression DSL embedded in a string with
double escaping.  Yuck!

Even something as simple as diff-in-a-string seems more appealing in
some cases than all these “substitute*” expressions.

-- 
Ricardo


  reply	other threads:[~2022-01-06  7:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 16:50 RFC: new syntax for inline patches Ricardo Wurmus
2022-01-05  8:16 ` Attila Lendvai
2022-01-06  0:19 ` Liliana Marie Prikler
2022-01-06  1:20   ` Jelle Licht
2022-01-06  6:43     ` Liliana Marie Prikler
2022-01-06  7:12       ` Ricardo Wurmus [this message]
2022-01-06  8:12         ` Liliana Marie Prikler
2022-01-08 21:34 ` Ludovic Courtès
2022-01-12 18:06   ` Efraim Flashner
2022-01-12 17:56 ` Efraim Flashner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87leztba9k.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).