From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id IOGdARzn7WAuXQEAgWs5BA (envelope-from ) for ; Tue, 13 Jul 2021 21:18:52 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id EH7UOBvn7WAXBgAA1q6Kng (envelope-from ) for ; Tue, 13 Jul 2021 19:18:51 +0000 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 883BB728A for ; Tue, 13 Jul 2021 21:18:51 +0200 (CEST) Received: from localhost ([::1]:57726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m3Nve-00056f-Be for larch@yhetil.org; Tue, 13 Jul 2021 15:18:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50798) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3NvG-00056R-DR for emacs-orgmode@gnu.org; Tue, 13 Jul 2021 15:18:26 -0400 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:44994) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m3NvE-0007j1-Gx for emacs-orgmode@gnu.org; Tue, 13 Jul 2021 15:18:26 -0400 Received: by mail-wr1-x430.google.com with SMTP id f9so35473wrq.11 for ; Tue, 13 Jul 2021 12:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QMMXlxN5sOUefTjvLp/gjvVJxmwQ7zrFVsw6xe8NMCs=; b=JCXfrgFYvJPA14gk+oJaeTfwa+G0Cv81SPeLUjlWVamF174xApp6ap9wNRNAPpdzsx +juWHZekrEspKpKIMqouQeg0uqjVZH8OO1HrTPrqcLWX7V8W5XaTeG+vJftYezY/xs0b oBzQv+hKXqy/owQqwjnfUPIUo4AVPUQojcM0mcafKUrp3w1mg+Ogm+hwyaLeOD7yfcuR TWWnBsmB8SQcKY4o+1RTsBCZ5BDJ5BA55CMy78JryXKyZnEmGQAV61iTKyIEop4AumU0 3O2q8YWossAXgB/BlfZfsMq+gJ97LYavJ0LZ9Ryg6Q4pFJEqr02iid487grWvcWYrSsr ad2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QMMXlxN5sOUefTjvLp/gjvVJxmwQ7zrFVsw6xe8NMCs=; b=Ft0zJyXfsQu/LcfFSnqmtlt3w8n/jW2S0IW2swh9qHaiM/0nOturms8YhMXElelKBf by8EKhnXhxKP1cSm89fo9ZsMXt+GzVXRsI6LJlc4GwdX2KhRJDeXXAdjcrzcGu3MV9xn aNtD63fTVtaMtoq+9f2Edq2B0/XYaTE+Z7yokHWewa5t3LMLNasdDUECjc8yb47hD7DX zmRFKO0jP5MgZj5HrLXeqU/jbLptNrvAsCHagmA+0WBFccrV38e3N5ycM9CY+ZKJkUNt Lp1GxbO+WAvEbP6EmrdADMTS8hehcsL5cze89mgvxzFqgk4kXn+y5nYmkmv9Urk8+8Oc Wq+Q== X-Gm-Message-State: AOAM530gQpdiw8EQqr1Hwtf+IKgBjzmKAlGt7nbouDOcg6Qywf5/WoiA +Ktx+AfBk6ivXtoU4htqPTP/+OprMTM2pDfWNRpvE3lJ X-Google-Smtp-Source: ABdhPJz4c8PT0t8wupJ7PFIAWgofytMyzVHCvKDfoldwDK/9ez3TzdJTFCcDNubSMrF8xMHttcVt5/fxg6B7rOri2SI= X-Received: by 2002:a5d:6b8e:: with SMTP id n14mr7549455wrx.96.1626203900749; Tue, 13 Jul 2021 12:18:20 -0700 (PDT) MIME-Version: 1.0 References: <95_WQAdCOQRo2u4VTanEqQ9QrbmOhFNk4aTCGlvgNU8PkVz3j7SQfwIZuwoxtQj0v5bGnRnP6NPf-Z6ImfWKpg_pHF6sTFHMgw0KVfir06U=@protonmail.ch> <9F8F3589-6E58-45AE-A0E6-F359ACA2A4D9@condition-alpha.com> In-Reply-To: <9F8F3589-6E58-45AE-A0E6-F359ACA2A4D9@condition-alpha.com> From: Tom Gillespie Date: Tue, 13 Jul 2021 12:18:09 -0700 Message-ID: Subject: Re: A requires/provides approach to linking source code blocks To: emacs-orgmode Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=tgbugs@gmail.com; helo=mail-wr1-x430.google.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, 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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tim Cross Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1626203931; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=QMMXlxN5sOUefTjvLp/gjvVJxmwQ7zrFVsw6xe8NMCs=; b=idn1LBa6T1lDsP8CJayzQGpNpt3n7jDGosdr8QKtO9InVfUdHY990v6qF1LiLSKmXl22H0 r5k9J2stG4WEOPjShCBaoJgGY1ZbX6ThF6X+CkULtist1vtrd9ojwuddF06bb1ketsRPI2 2Pbd3bdOrZ97F2C6c8nUOnc/VNgucTnIu7W6hw3mxbtMsl5N9RzPeS93U0dCNXLXq2OM46 qqXD7xWDqGmOquCGb6ZfCvPESJFKtD5CAHgWjftsAgW2esAlNiVXhxXgp+LLjta74rawb/ Os+esJyl3H3jdcDzQLv5j4LJyKtRPHHxRt797pDjX6fCLmUvLxzb74WjKWk+gA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1626203931; a=rsa-sha256; cv=none; b=EZ+DnP9FpPkj539WIOEQARtdnfriUDRuJ4xefggahTOMRGjk6tXlBT/7YNTQT5SjlKwh6E JZOq1+yJBYfne5snNq+9leJ7jqdkETsHlHIT6WSAo8mRhtjonUFGdIoL3ezsXaVC6YreO/ 7OJocN822UOT0RLKZgY4Q72De7L1GotKboY01X6EVKGXJPSoBh+jadMnoMxPIuXFXqhYD8 DmuzQ7IEfgmtw+JmJtWUCH/NPV1yFoTihRTcQ1VPlMNZdcvaS3cn3MlrGheHOsC2/Fq2AJ 6W78bW7xUOOhfNaVe68XB2g39gtXkrfQaqoC6qdvTiGzTN92S7tHIjM4jRbDiw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=JCXfrgFY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -3.10 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=JCXfrgFY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 883BB728A X-Spam-Score: -3.10 X-Migadu-Scanner: scn0.migadu.com X-TUID: j1/InKfFkNtt We have been receiving many new feature suggestions and requests coming in for org babel. I think that Tim's suggestion is the right one. Nearly all of these need to be implemented as an extension first and tested independently. Further, even if this is done, it should be clear that there is zero expectation that such extensions will be incorporated. Once I wrap up the formal grammar for org, one of the next things I plan to work on is a clear specification for org babel. This is critical because so many of the suggestions that come in deal with individuals' specific problems and thus fail to account for how such features interact with existing features and how the newly proposed feature would block some other features in the future, confuse users, etc. Such suggestions also often fail to account for increased complexity, nor have they been exposed to a sufficient number of examples to reveal fundamental ambiguities in how they could be interpreted. The issues with variable behavior between ob langs for :pre :post :prologue :epilogue etc. are already enough to keep us busy for quite some time. With regard to this thread in particular, it is of some interest, but there are fundamental issues, including the fact that certain languages (e.g. racket) expect module code to exist somewhere on the file system. There are ways around many of these issues, in fact there are likely many ways around any individual issue, so org babel needs to systematically consider the issues and provide a clear specification, or at least a guide for how such cases should be handled. To give an example from one of my continual pain points: I start writing python or racket in an org src block and then I want it to be a library so that it can be reused by other code both inside and outside the org file without having to resort to noweb. What is the best way to handle this? I don't know. Right now I tangle things and resort to awful hacks for the reuse-in-this-org-file case, but I'm guessing there is a better generic solution which would allow _any_ org block to be exported as a library instead of nowebbed in. Before jumping for any particular suggestion for how to handle this we need to explore the diversity of cases that various ob langs present, so that we can find a solution that will work for all of them. After all, packaging code to a library for reuse is an extremely common pattern that org babel should be able to abstract, but it is a major undertaking, not just the addition of a keyword here and there. In short I suggest that we issue a general moratorium on new org babel feature suggestions until we can stabilize what we already have and provide a clear specification for correct behavior. Until we have that spec we could encourage users to create extensions that implement those features. Best, Tom PS The other next thing that I am working on might be another way out for this particular feature request. Namely, it is simplifying and extending org keyword syntax so that new keywords (with options) and associated keywords can be specified using keyword syntax within a single org file. This would make it possible to get useful high level keyword behavior in a single file without burdening the core implementation with more special cases for associated keywords, and it would allow users to write small elisp functions that could do some of what is suggested here, all without need to add anything to the core org implementation.