Re: RFC: new syntax for inline patches

[Ricardo Wurmus]

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