From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id MGsdM3SY1mHOtAAAgWs5BA (envelope-from ) for ; Thu, 06 Jan 2022 08:21:24 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id OA5hMHSY1mEqiwAA9RJhRA (envelope-from ) for ; Thu, 06 Jan 2022 08:21:24 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 906C910E1D for ; Thu, 6 Jan 2022 08:21:24 +0100 (CET) Received: from localhost ([::1]:40908 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5N5P-0002SS-AM for larch@yhetil.org; Thu, 06 Jan 2022 02:21:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5N4v-0002Pt-A8 for guix-devel@gnu.org; Thu, 06 Jan 2022 02:20:53 -0500 Received: from sender4-of-o50.zoho.com ([136.143.188.50]:21092) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5N4t-0004pV-0X for guix-devel@gnu.org; Thu, 06 Jan 2022 02:20:52 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1641453647; cv=none; d=zohomail.com; s=zohoarc; b=DvPCTcNvUj1lynWQKv6AyNp+1/Jmvm4iZtbXyySm4DAEma97soP0S5QhFH5zhN4/pn2/VoedWrK4ce/uOhWVzW+7ccEosargvW7js8mhqiOPmzsx1G4SS8qAZ13wzfOMg7RMlkm+wTgdxuRYP8OgCUe98Q21Ybj2DuIbOVztWTA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1641453647; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=BFlcygnYDxpQXx1bKh9KrQR1DpsuslfXWo86zRFFazw=; b=AIgcHfTF0fFl0y7JOYTqo0Gqr5tRbGqtp1oRY0OCd8iyFEAMgcqClrVDRueAXLFNvBAhQ7ZPRm8uQoNLN0FY/TEdzyCSAYEt615IcIH7c3YnqPjXPlCDzEyBbRvxbORa2Cut3ZoNycceksYmZGCrxcILpxzq3MnuiFHkiiHhkXc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1641453647; s=zoho; d=elephly.net; i=rekado@elephly.net; h=References:From:To:Cc:Subject:Date:In-reply-to:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=BFlcygnYDxpQXx1bKh9KrQR1DpsuslfXWo86zRFFazw=; b=OHYzQESd/059kwv7bq+VBMA6aIB2B631SQO2SebsmrroIgOJReFYpPJq37qnDn8U IIdsjQnH6Oz5sFpdRXdFMB4NdfFTSOlCJTtXyTtAuWoTKKlBPawcD3HNsL45v0XePZe +2oOAiY2J0UvU8hpbtyTvmN/SsVz+6iqdNR6xllQ= Received: from localhost (p54ad4f9a.dip0.t-ipconnect.de [84.173.79.154]) by mx.zohomail.com with SMTPS id 1641453644236578.5036225704981; Wed, 5 Jan 2022 23:20:44 -0800 (PST) References: <87ee5ne7z5.fsf@elephly.net> <9781ffb5ec81b2d7c58dd171239510e27eef3c79.camel@gmail.com> <861r1lacdd.fsf@fsfe.org> <91c6c25534e422d893a3dd219633a2e7ff3f1a68.camel@gmail.com> User-agent: mu4e 1.6.10; emacs 27.2 From: Ricardo Wurmus To: Liliana Marie Prikler Subject: Re: RFC: new syntax for inline patches Date: Thu, 06 Jan 2022 08:12:03 +0100 In-reply-to: <91c6c25534e422d893a3dd219633a2e7ff3f1a68.camel@gmail.com> X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Message-ID: <87leztba9k.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.50; envelope-from=rekado@elephly.net; helo=sender4-of-o50.zoho.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641453684; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=BFlcygnYDxpQXx1bKh9KrQR1DpsuslfXWo86zRFFazw=; b=RWRZ0eGuzNPKl8jWcyfaY7Bkot/eoVS7wejAHhuqKMxeDludBOFNHEUfVRSTpqDSoxnlZJ 1tUUEl9A4SLtZF8rSd4Y39YPxmpdceUQivlQ/To9SlIYw6B8hIb5ukhGZde6QFjYAJmu+d nU8IDyvTruDMvB7uN4Zpjp8diQ/oj9Hi6OXrPIFzT3zOrZ84ExGne8tNxVE+afAj5k/WsI EilIGuYIo5pnAkQRTk5YWr6tcjVdCS+WqmardcpaxoQTxFj0ciUI0B2OzKqbPVLw1P7hZk 29RHTKeITJ4fMWHWx8r60VFAjKLtlBrBSbehG0+QG4rOj0VGJMur412xyLJjJg== ARC-Seal: i=2; s=key1; d=yhetil.org; t=1641453684; a=rsa-sha256; cv=fail; b=KHiQ1tEOSn7Sq+ZAD+f5lGRlcK/WEqzT9srIphM1bTgsVxDyA72O5ClNutn4KOyt7ML2uK UUXl6iH2OG4TKY6Syye1KXA5QIqnmZUDkIwI8Y5O15K1uNJzV03Ai0tPKuoCAwDae8Trdz 3UVYNm5oOyp3l/2q9NvW0YkQ9f85AdlR9otk5SH0UrApwuu2CzF+zSCjCHrUQwrJ9pGHI+ 3KYKBMxzx+UXNuPOCcdMEdy2VTY4rI0dhYjj8hIGGmmVz+AK08efk5APBsU9CD8H+XR7gc GfJNOESkKCGY85Ej1KW5JZusRbHyo63Awl2ScE6FJLEKyEoKUVduXYvFYbj0cQ== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=elephly.net header.s=zoho header.b=OHYzQESd; arc=reject ("signature check failed: fail, {[1] = sig:zohomail.com:reject}"); dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.60 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=elephly.net header.s=zoho header.b=OHYzQESd; arc=reject ("signature check failed: fail, {[1] = sig:zohomail.com:reject}"); dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 906C910E1D X-Spam-Score: -1.60 X-Migadu-Scanner: scn0.migadu.com X-TUID: fvewkU3vlqwF Liliana Marie Prikler writes: > Am Donnerstag, dem 06.01.2022 um 02:20 +0100 schrieb Jelle Licht: >> >=20 >> >=20 >> > > Here=E2=80=99s a colour sample for the new bikeshed: >> > >=20 >> > > =C2=A0 (arguments >> > > =C2=A0=C2=A0=C2=A0 (list >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #:patches >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #~(patch "the-file" >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((line 10) >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (+ "I ONLY WA= NTED TO ADD THIS LINE")) >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((line 3010) >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (- "maybe tha= t=E2=80=99s better") >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (+ (string-ap= pend #$guix " is better")) >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (+ "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. >>=20 >> 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=E2=80=99s like loo= king at bikeshed colours on a screen: they just don=E2=80=99t pop right, and dependent on screen calibration or lack thereof they can seem outright hideous =E2=80=94 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=E2=80=99s primarily a matter of style and readability. I think it=E2=80= =99s 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 =E2=80=9Csubstitute*=E2=80=9D, and then = the =E2=80=9Csubstitute*=E2=80=9D 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 =E2=80=9Csubstitute*=E2=80=9D expressions. --=20 Ricardo