From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id +J6fBSrWWV98XQAA0tVLHw (envelope-from ) for ; Thu, 10 Sep 2020 07:30:50 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 6CJdASrWWV8FYQAAB5/wlQ (envelope-from ) for ; Thu, 10 Sep 2020 07:30:50 +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 43BF594036A for ; Thu, 10 Sep 2020 07:30:49 +0000 (UTC) Received: from localhost ([::1]:46330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGH2d-0004MA-Nn for larch@yhetil.org; Thu, 10 Sep 2020 03:30:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37418) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGH1w-0004Kn-9t for emacs-orgmode@gnu.org; Thu, 10 Sep 2020 03:30:04 -0400 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]:45233) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kGH1t-0005CU-Go; Thu, 10 Sep 2020 03:30:04 -0400 Received: by mail-ej1-x62d.google.com with SMTP id i26so7190432ejb.12; Thu, 10 Sep 2020 00:30:00 -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=G+H/IE/qZjfnTc06PzT+bHM/mOGtCPY4fptJvW4qkP0=; b=l/12C3hRJ6bHchW1d6BJRyj1zKeNBHeeKtTFFjq5wfJ/PmBDkbf44kH+jl6TzexXyc x4QE8r3LnW+rxgAKZtX0pGIG9sxxdTiENsdROMAkOY2rN29lqkhM54c1qdRdg1+j2RcZ XFv0B+fKG0I2JT1GAlnrrUU2w5EjhuP5pClwhcZMnoyovU2yg5cc2L/qTmnHUnAmeDTz EXfXg5jU7+mcC7FdDs/BmrRCKz5mmo2Fsl1bP9W8/wwdpdRNL4PXFfbphWTS0utOsHHg DpmbzB3HkjJc6aS2qrdmKkUd63MX5nSXZvEOp3jHOlf86Enttc2ImSMSCgRutn9y5Ewc Mhgg== 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=G+H/IE/qZjfnTc06PzT+bHM/mOGtCPY4fptJvW4qkP0=; b=TY9p0+0yDYv17Hmrpx5J354+Ta2JZ6oi1wXrKSU3wPCaV0mxS5jKlJOwCKBi1bNq5R cfonuwjbMv8VELanI/j92pJe4DUsRp6NhVreMhUd8fl1gUlcWjJGZPDMR2QIuL1FZt+i 7leJnjXBca/DwRDItFOgnMjBN4oovLcl2porsHP2XkYtGWSs8c777yED7frBon+gsk/J aZqlkyxv8pxPxcPB8z0Lx/p97PwW+ubbtfWAaD9o6fjvHYV/yAEEox982VORQSeczt6+ wOFc94Rs2vVCSsFdLaFPgImMoPPB922ev/tK6aoD0roTWhAb90rjE3/l9GVPkIzatUGY 7jFQ== X-Gm-Message-State: AOAM532/tbQ7WdK32hI+cpGuyDNOPIlR4Ksvvqp7HVuljuULoXjaW/40 XTYnDLbwk92OaavUajoE5gHzJJUSVyMQl5IF3jc= X-Google-Smtp-Source: ABdhPJzc35Wj15b9hEzVY3kiDKRROGx6IqI/sfvQPAA038tFWmqc66XI9va2t6huRN5ZbMQi9HauSzgA3meyrjlwrpc= X-Received: by 2002:a17:906:b317:: with SMTP id n23mr7334273ejz.6.1599722999531; Thu, 10 Sep 2020 00:29:59 -0700 (PDT) MIME-Version: 1.0 References: <87y2loakcw.fsf@gnu.org> <87d030ae7g.fsf@bzg.fr> In-Reply-To: From: Vladimir Nikishkin Date: Thu, 10 Sep 2020 15:29:48 +0800 Message-ID: Subject: Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value? To: Tom Gillespie Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::62d; envelope-from=lockywolf@gmail.com; helo=mail-ej1-x62d.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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: Bastien , emacs-orgmode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=l/12C3hR; 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-Spam-Score: -0.71 X-TUID: VPO+Rlezs2O2 Well, why exactly Racket people decided to introduce the #lang directive in such a way that it looks like a shell comment or a shebang line seems to elude my understanding. (declare :lang 'whatever), at least to me, seems much more lispy, and even (read) able by a standard reader (which could later be switched to a different mode). >because the shebang line will not actually be included when executing the code How so? I never had problems using shebangs in my code. They seem to be prepended to the autogenerated files in /tmp/org-* just fine (in some other function). >due to the addition of a prologue section When does this happen? :prologue seems to be already included in the 'expanded variable. >It also becomes necessary to remove the shebang line from the edit buffer C-c C-v C-v does not make an edit buffer. It expands the buffer for a preview. I never suggested to prepend a shebang to the C-' buffer. In fact, saving the C-c C-v C-v buffer is the only reasonable thing you can do to it. Editing it makes no direct sense, because expansion is a many-to-one process, and you cannot "unexpand" the buffer (without evil diff trickery at least). >the need to keep what will be run by org babel in line This actually _is_ about keeping the two things in line. When evaluating a noweb-enabled block, and in fact, any block, org already prepends the :shebang value. I'm just suggesting to make the preview consistent On Thu, 10 Sep 2020 at 15:11, Tom Gillespie wrote: > > Hi Vladimir, > I have encountered similar issues with wanting to have a racket > #lang line included in a tangled block while also allowing org to know > exactly which #lang it is working with. I haven't found a good > solution. One issue with embedding the shebang when editing a buffer > is that it is very likely to cause confusion because the shebang line > will not actually be included when executing the code, or if it was > included then there is a reasonable possibility that in some cases it > would not be included as the first line due to the addition of a > prologue section. It also becomes necessary to remove the shebang line > from the edit buffer, which means you have to know which shebang lines > were added automatically and which were not. Further, the need to keep > what will be run by org babel in line with what is shown via these > various views makes it seem unlikely that this should be implemented > as default behavior. I have a long email that touches on these issues > in the works for after the 9.4 release, so thank you for providing an > excellent example. It seems like one possible solution for your > workflow would be to advise org-babel-expand-src-block to insert the > shebang. Best, > Tom > > On Wed, Sep 9, 2020 at 11:53 PM Vladimir Nikishkin wrote: > > > > So, my point is the following. A shebang is an almost universally > > accepted way to specify which interpreter should be used for code > > evaluation. > > > > In the ob-core.el, at line 787, the function called > > org-babel-expand-src-block makes a buffer out of the noweb-expanded > > code. > > (I am working with org 20200907) > > > > The sexp is looking like this: > > > > (org-edit-src-code > > expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*")) > > > > I suggest replacing this sexp with > > > > (org-edit-src-code > > (seq-concatenate 'string (or (alist-get :shebang params) "") "\n" > > expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang " > > ]*")) > > > > This way the expanded buffer would respect the shebang, and the > > resulting buffer would be saveable as a runnable file. > > > > I suspect that the second branch of the (if) should be left as it is, > > because non-interactive usage probably means that the code will be > > used later as a part of something, and therefore does not need a > > shebang. > > > > Vlad > > > > On Sat, 5 Sep 2020 at 15:13, Bastien wrote: > > > > > > Vladimir Nikishkin writes: > > > > > > > I'll try to do one this week, but I can't submit a patch officially > > > > because of my employer being staunchly against signing the copyright > > > > disclaimer. > > > > > > :/ > > > > > > So please just give directions on what to modify and how, and that'd > > > be enough for someone (probably me) to get started. > > > > > > Thanks! > > > > > > -- > > > Bastien > > > > > > > > -- > > Yours sincerely, Vladimir Nikishkin > > -- Yours sincerely, Vladimir Nikishkin