From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id mGzIAFgFOWbGSwEAqHPOHw:P1 (envelope-from ) for ; Mon, 06 May 2024 18:29:12 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id mGzIAFgFOWbGSwEAqHPOHw (envelope-from ) for ; Mon, 06 May 2024 18:29:12 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UpnVdigV; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1715012951; 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=BCkZZgnzKBIJfApRiXtpkwl6TbzNnf/8YDQI+yZ8bXs=; b=Ve3oxo0HiVLR757+KxWxGZ4ffG4yI428D+p+LPkblfOCoLKxvYuxuS36D58XzaG9q7qNKW 4zhHoU3gt9xvsH8oNozQwnIZugkmYYRe5aCDxcnPUALhugHqocCyLs3OmT82Z9/BFLWhpc XpHnDvrv4XsDF8zhaPgr2SJArqznorCOIUpCcRvq5J3YyDUO2CbzDyZqN6U9aVkRw2jVFQ 2N+HEdYz/lTGMhs7l6K+DU0+Q44kZP5C8eMq9IofjBCcG3gtlCOPA2sAIn41Yq1OnlpyfZ 4zl3rOKmPuttkpoClvPbzexiDGQFwJKyhlJpCp3Dl0fTClLkyV32z9+GMbi32g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UpnVdigV; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1715012951; a=rsa-sha256; cv=none; b=hQrfzo0WK795Oo3B+uluA2T/YIZ3AfgZNXchMbCRhcyN3APjQr0huGIwHuETztNOg30dSk B9wVxf0PvJ0pBC31iCweOg6HZSUrmXQS5mADG5B38ukxFXt6ICWctSINwd3GmfEzQWvCa8 cOBYnlJQYlJwTIEKIp399Gfa0P16VNJ5fghs/xlZyTvgVq+4UOt6gBa2/VfHoYiYO8ViIS 9Vzc4mqcaELafZOXh+R1hcgkDKZmIuLi5mqnObOv8Jk0t1hjCtDx8RDQu5CEYcL/w/dH5E RCpUZv6eWCaYlTNAeO3+zO8RhhMxblms04/zg5WuLYsxIbA1igisMIxAcxWUbw== 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 A6E8311D78 for ; Mon, 6 May 2024 18:29:11 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s41CU-0004uq-MK; Mon, 06 May 2024 12:28:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s41CR-0004ue-7m for emacs-orgmode@gnu.org; Mon, 06 May 2024 12:28:23 -0400 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s41CM-0004Hv-9x for emacs-orgmode@gnu.org; Mon, 06 May 2024 12:28:21 -0400 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-41c7ac6f635so14451125e9.3 for ; Mon, 06 May 2024 09:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715012896; x=1715617696; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=BCkZZgnzKBIJfApRiXtpkwl6TbzNnf/8YDQI+yZ8bXs=; b=UpnVdigVstcTVD2GSsqAdSoooe2zFGCpkRmSVhwMmJLBDxjr+S33dD4lKUMwXQ5zLU u8Ft/xJEsBj+CWbLqUvoGGa4QsEE/nk1Uo1v8+PEBtMeFp4lucDu0t/atuaVbxrEMZ4K pidfatOGLEydJ5R48gK+SzhfHOtek66voB853ZBEhxOF/i9PItbk83Bx4WbwtpdWtGr/ JiPOdbUV6qayY/RLVPqR2+blyTqfMGdRmtRkc8T4P58BYdHkFqRmz0oMrwooHnvhNMyn V8iTtuaIwCvKSe56s6FWBjbCXSvGDjWYGbQEZlos6TPbifcmpKCjdZ8pcaDmwWSzxjpg V+Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715012896; x=1715617696; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BCkZZgnzKBIJfApRiXtpkwl6TbzNnf/8YDQI+yZ8bXs=; b=qYFltkqCUK6329PpLkVYOpQFDk5JpThcGIMXml3mafsMieJaEueK2lgIKINnLSD1cN avOI2ZNVHmc6yQSckw0MuLyGjoRSAPusmuyoaGU4ZSaHR6E1tCDpXM/6+4IZy4qalFKF FLAd792bzYAWGhHzHzjdcPcLQLSQono6IMEzYAFJhh7X+4DsU4M3xABVe2qSvqxG0arP qt/3UQjtXXPYzGKNA3cedOzZSesiV69Gp6HCL9QzF2YSRDRGcmJda8qCX6sEW8fVl3AA Mrmd65pV4ZvjgfNbRtmb9A/49cqb2q6mgv4NZn+dvb+SsFNCW3Wu/oE8Gn2fc/uIhZbA XDrQ== X-Gm-Message-State: AOJu0Yx9YbRtFtmE32Ym65BtRFbkqLNrvqEJ8XZwFNaibZhVcVpHtdca KobC5WV22fJ6NEJPusjS86tCckGrX5cyq/AphWVExs5sHnBvHUrTp24U2w== X-Google-Smtp-Source: AGHT+IFIwymWTQrI3aOyEUjLWMMQunGgg0GFTVuXo7+ymKiJI2k3ZOn3BQHhPXnkLCzZAoqmFjtsQw== X-Received: by 2002:a05:600c:4713:b0:41e:62e2:f55f with SMTP id v19-20020a05600c471300b0041e62e2f55fmr7340698wmo.18.1715012896166; Mon, 06 May 2024 09:28:16 -0700 (PDT) Received: from hayvan (pharma2-70.w2k.pharmakol.uni-freiburg.de. [132.230.165.170]) by smtp.gmail.com with ESMTPSA id iv19-20020a05600c549300b0041c04022336sm20490378wmb.9.2024.05.06.09.28.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 May 2024 09:28:15 -0700 (PDT) From: Mehmet Tekman To: =?utf-8?Q?Jo=C3=A3o?= Pedro , Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: [ANN] lisp/ob-tangle-sync.el In-Reply-To: <87cypz3dp9.fsf@ergo> References: <87wmyc1sud.fsf@localhost> <87r0ok1qx4.fsf@localhost> <87o7jo1q2s.fsf@localhost> <87pm43kz3i.fsf@localhost> <87o7jlzxgn.fsf@localhost> <87fs1e0wue.fsf@localhost> <87leb60w98.fsf@gmail.com> <87a5qg97rx.fsf@localhost> <87plzcke46.fsf@gmail.com> <87bk5sg34s.fsf@ergo> <87y18w397w.fsf@gmail.com> <878r0wf8cs.fsf@ergo> <87ttjc435m.fsf@gmail.com> <87cypz3dp9.fsf@ergo> Date: Mon, 06 May 2024 18:28:14 +0200 Message-ID: <87plty52ht.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::331; envelope-from=mtekman89@gmail.com; helo=mail-wm1-x331.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.71 X-Spam-Score: -9.71 X-Migadu-Queue-Id: A6E8311D78 X-Migadu-Scanner: mx13.migadu.com X-TUID: DLB4VpT3eYx9 Hello! Jo=C3=A3o Pedro writes: > So, if I understand correctly, =3Dheader-reform=3D is where we're at right > now and after we're done with this overhauling of the parsing of > (mutually exclusive) header params, we'll get back to the actual syncing > logic, which should be mostly done. Exactly -- reform the headers first (branch: header-reform) and then add the sync stuff later (branch: ob-tangle-sync-2023). > Ok I'll start here as I think writing tests could give me some more > insights on the core problems that still need solution. Yeah, at least from my side I got really confused with what the expected actions of some :tangle parameters were. Let me know if you find any ambiguous cases too. > 1. So the idea is to continue parsing multi-option header arguments into > their separate components, but have a common place to, after parsing > it into their components, handle them all in a single place? I mean, > what does "handle" mean in this context? Hah, good question. I think by "handle" I mean three things: 1. Ensure that :tangle remains as the raw string :tangle so that other parts of Org can use it without needing to guess if there is a sync action in there or not. I quite like Ihor's suggestion: Ihor Radchenko writes: =20=20 > we need something like > > (org-babel-get-header-arg :results params) ; get parsed parameter > (org-babel-get-header-arg :results params 'raw) ; get raw parameter > > Then, babel backends will not need to know the internal details about > :results parameter being represented in its two forms stored as :results > and as :result-params. 2. Ensure that :tangle or :tangle-params can merge both filenames and sync-actions down the hierarchy. In my last email I talk about "process-params" (splitting the filename and sync-action) and "merge-params" (resolve hierarchy) as two separate entities, where a :tangle header is first "merged" down to a header, then "merged" down to a subheading, then "merged" down to a source block, and then finally "processed"... ... but now that I think about it, it's quite likely that "merge" and "process" are interlinked, and we will need something that is aware of what the "filename sync-action" pair is, at EVERY level of the hierarchy. As in, it processes a header first, then merges it down, then processes the next header, and then merges that down, and so forth. Right now, process-params and merge-params are two independent code blocks, but I think one might need to start calling the other. 3. Do this in such a way that :results can also benefit from this process/merge strategy. > 2. Isn't that the same as the previous point? If we can handle any > *-params doesn't that solve the problem of handling mutually > exclusive groups? Yes, it's the same point :-) Creating a unified *-params handler for mutually exclusive groups would probably fix all 3 problems.=20 > We can just define a pattern of parsing them into individual *-params > and handling that in a unified manner. If I'm understanding you correctly, do you mean we leave the normal header merging and processing alone, and we just treat :tangle-params and :result-params as their own special group, and handle them independently of :tangle and :results? If so, I'm not so sure how easy it is due to my second point above. > Are these patches also on the branch (apart from the WIP one)? Yep, those patches as well as the WIP one are also on that branch. My coding strategy right now is to develop chaotically on =3Dheader-reform=3D and then do cherry picking/rebasing afterwards. If you want I can give you push privileges to that branch, or you can clone it and work in your own tidier manner, or do you prefer working with email patches? Best, Mehmet