From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id KDeRClTcL2HuTgEAgWs5BA (envelope-from ) for ; Wed, 01 Sep 2021 22:02:28 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id sJMLBlTcL2FueQAA1q6Kng (envelope-from ) for ; Wed, 01 Sep 2021 20:02:28 +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 64B03195AE for ; Wed, 1 Sep 2021 22:02:27 +0200 (CEST) Received: from localhost ([::1]:48184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLWRF-00035k-Ga for larch@yhetil.org; Wed, 01 Sep 2021 16:02:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLWQU-00035B-EK for emacs-orgmode@gnu.org; Wed, 01 Sep 2021 16:01:39 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:43882) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mLWQR-0007tX-NK for emacs-orgmode@gnu.org; Wed, 01 Sep 2021 16:01:38 -0400 Received: by mail-wr1-x42b.google.com with SMTP id b6so1347791wrh.10 for ; Wed, 01 Sep 2021 13:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vicarious-living-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6xyZ2nNiA6EAeTEsBs+KdLnlRRFuErhp3h4MxyuyNWA=; b=sBEwyQaS+ym/t3wjMdu1Llc36hwCUE79H9t7ss8th3+rc61GkdN7ImEfNaAdsoMbl9 /ay0hqwtRWnvzgvfJ5Ck55GI1P2JaPkSVvVz12WzBkeJnhzkIoL5E8nswiUeJdIOm9FD bH2Nnf5hQz1iQZHsR0zSpIawPRGi8FFFKKkItZiZJPtQ44F6QQ6wfiLpgF6BHmTSLz6N Wci0M4qB1QokTXn3pTrLUHdx+14KAS0fQEmhOSIwDG+1nRFx2j2IbsjbH6FLI7OrCh1+ Ar6wTzHzFUkpZ2AkvHZin8VDC6Pf92sk7Ud4C+MXFbXTR19Sc3qss9o6pTgJoMQzvkMC 8hsw== 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=6xyZ2nNiA6EAeTEsBs+KdLnlRRFuErhp3h4MxyuyNWA=; b=tSGeTIB2OkShFOFn9RGT3SQVVqS61OtEo4HWULZgKOPiS9/7HQe6zs7oyF/vr2IHuy 1rvXCWkE8UQ8f+1K5nVFGHFlnZ5LqeaIRA3qAruYcYxtF67chTYPumPYalqiwKfm5CQL 2CJQBSL7ay76JLgMXpdrQ4nTntkQNzpvE+XyHQBMpSmhrdVK1WRkJrAnmuIWPHS10SwW /NPCgrA4ozypFWMLNAGwpoS34jPvSlJzYjSAJfZA8cbVZACn9p/7uf+9ewndi1oTcrT0 TBrBjq2H3K0NXTY84tLu1mCe20smVxRHyzspiqOOcnhH9ZdBjbsUtey02fmULsefQ4DQ p5lQ== X-Gm-Message-State: AOAM530ppr0boMr9gBiHB67eHxV17a+SNf6SXqla8FC1VJNODHNhuWyx XzTnQDo2zxEE6bd+Bd9KyGgmsiGDEItklsCqCbRlwg== X-Google-Smtp-Source: ABdhPJx+PIGetYo38BD98DxbaDmzVUFhajW05PSLahfAPEavvExharCdgDdWjPZCwBotXc3Rhx+EupFPuLPfMhBU5Ic= X-Received: by 2002:adf:b318:: with SMTP id j24mr1274780wrd.84.1630526492784; Wed, 01 Sep 2021 13:01:32 -0700 (PDT) MIME-Version: 1.0 References: <878s0hq2kc.fsf@gmail.com> <87lf4gxskm.fsf@localhost> In-Reply-To: <87lf4gxskm.fsf@localhost> From: Ryan Scott Date: Wed, 1 Sep 2021 13:01:22 -0700 Message-ID: Subject: Re: New source block results option for attaching file to node To: Ihor Radchenko Content-Type: multipart/alternative; boundary="00000000000066482005caf48868" Received-SPF: none client-ip=2a00:1450:4864:20::42b; envelope-from=ryan@vicarious-living.com; helo=mail-wr1-x42b.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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: emacs-orgmode@gnu.org, Timothy 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=1630526547; 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=6xyZ2nNiA6EAeTEsBs+KdLnlRRFuErhp3h4MxyuyNWA=; b=VYq/2hxi2jNt8Id5/91vd7/JHuqW0EixAYWCXX83rDqeftzVbe8aXJEgxo+KxenMizOHPo KAHaXNFf2rHyJPHCjPI709FPyXYDDtiC06gqiYxaVLJI3K7uy6CQXXYj1LXe6O0GOSWWAm ezu+80QTYPhANPl1j+5lQt75NAkE50MpNzv3oTC3jY7UelLcmYBdjvl9HPs1qjdFxED/OM qQX3wgjw5yoNSPsiqILfhdb5PWmAwE3rrCLxGrzKWUKCAy7zesl74MWmosuMdqnr+9yLSK xtTlSwIIxxKiB7MUMLkRhqzpk8qV9UF3a+48vtLYAYsk+3KteO4Ou1Xq63GgGg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630526547; a=rsa-sha256; cv=none; b=bA7mHBHqMt2/7jf+aZ5lpDMyWGeKOy+/ItuHoM7rroz65QVE6dJBMzF/VRiNwHYztZ4tfK SsPKsbcjcQxDdnRxR4SOtYH0HoH8XhjjHRah8UrUtWGMFOV8ybHpzTHiVSs0p/RgUD97/i JDuRCxz1k232Dk3tKSuwA0mX64nDAvxKq0XqEVohfUmMqxPn4BnB/4rbhQniw4UXmOPpQc 18/ubsiFRiXfeEsp6Aldeq/Ow/4iTimkYiY8ovejfIFk+ilIkwzu8DctHxEisqZhtaK9Wx DbKFXaHhMTXLsI+BHrtJHNrQIc5mGqXiZhBcE87T51pk4A4q0CmTMUMWNek/Tg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=vicarious-living-com.20150623.gappssmtp.com header.s=20150623 header.b=sBEwyQaS; 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: 0.08 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=vicarious-living-com.20150623.gappssmtp.com header.s=20150623 header.b=sBEwyQaS; dmarc=none; 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: 64B03195AE X-Spam-Score: 0.08 X-Migadu-Scanner: scn1.migadu.com X-TUID: 3y2K2Is9txNX --00000000000066482005caf48868 Content-Type: text/plain; charset="UTF-8" I hadn't thought about input directories much as my usage of graphviz/gnuplots is through [essentially] DSLs that I made for them, so the blocks are actually elisp. Perhaps a convenient way of setting the working directory to the attachment directory per-block makes sense? My own personal coding style doesn't include a hard line limit, so it just wasn't on my mind. I'll get my patch updated and submitted shortly. Thanks for the help! On Wed, Sep 1, 2021 at 7:44 AM Ihor Radchenko wrote: > Ryan Scott writes: > > The patch looks fine for me except a typo: > > > + by the source block to the nodes attachmen directory (as > ^attachment > > > org-attach-dir is a function for me (latest org pulled using straight.el) > > org/lisp/org-attach.el:327. > > Timothy probably does not have (require 'org-attach) in his personal > config. However, it should not be an issue for your patch with the > autoload you added. > > > The primary use case is src blocks that generate files, in my case > usually > > gnuplot or graphviz, and return a file path. With a collection of org > files > > in a directory, organization can get messy, and creating an > organizational > > scheme essentially recreates the attachment directory design. > > I am also using attach directories for gnuplot output. Your approach is > fine, but what about input directory? I find it a bit awkward to store > input files alongside with the main .org file, while keeping the output > images as attachments. > > I personally prefer to set the working dir for gnuplot like > > #+begin_src gnuplot :dir (org-attach-dir) > > With my approach, both the input and output files are going to be in the > attach dir. > > I even go as far as making attach dir my default directory of all the > code blocks. > > Though your patch may be useful when input directory is read-only or > even remote. > > > Another approach would be to instead only modify org to have hooks (or > any > > other callback mechanism really) that are run on link insertion and have > > access to the result-params for the block. The rest of this could then > be a > > separate package easily enough. Would that be a better approach as it > would > > allow the org core to not be so tightly coupled to org-attach? > > org-attach is in the Org core. It should not be a problem supporting > org-attach in org babel. > > > I'm using magit; I just don't normally restrain myself to the line > length. > > I'll make sure to do that for submitted patches here. > > You may find flycheck-mode useful to hint things like line length. > > > In terms of this mailing list and overall contribution process, how best > to > > remedy things for the patch? Just modify it and reply with the modified > > patch as an attachment? > > Yep. Just submit the updated patch. Preferably, also add [PATCH] at the > beginning of the message topic. Then, the patch will also be shown in > updates.orgmode.org > > Best, > Ihor > --00000000000066482005caf48868 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I hadn't thought about input directories much as = my usage of graphviz/gnuplots is through [essentially] DSLs that I made for= them, so the blocks are actually elisp.
Perhaps a convenient way= of setting the working directory to the attachment directory per-block mak= es sense?

My own personal coding style doesn't= include a hard line limit, so it just wasn't on my mind.

I'll get my patch updated and submitted shortly. Thanks= for the help!

On Wed, Sep 1, 2021 at 7:44 AM Ihor Radchenko <<= a href=3D"mailto:yantar92@gmail.com">yantar92@gmail.com> wrote:
<= /div>
Ryan Scott <ryan@vicarious-li= ving.com> writes:

The patch looks fine for me except a typo:

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 by the source block to the nodes a= ttachmen directory (as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^attachment

> org-attach-dir is a function for me (latest org pulled using straight.= el)
> org/lisp/org-attach.el:327.

Timothy probably does not have (require 'org-attach) in his personal config. However, it should not be an issue for your patch with the
autoload you added.

> The primary use case is src blocks that generate files, in my case usu= ally
> gnuplot or graphviz, and return a file path. With a collection of org = files
> in a directory, organization can get messy, and creating an organizati= onal
> scheme essentially recreates the attachment directory design.

I am also using attach directories for gnuplot output. Your approach is
fine, but what about input directory? I find it a bit awkward to store
input files alongside with the main .org file, while keeping the output
images as attachments.

I personally prefer to set the working dir for gnuplot like

#+begin_src gnuplot :dir (org-attach-dir)

With my approach, both the input and output files are going to be in the attach dir.

I even go as far as making attach dir my default directory of all the
code blocks.

Though your patch may be useful when input directory is read-only or
even remote.

> Another approach would be to instead only modify org to have hooks (or= any
> other callback mechanism really) that are run on link insertion and ha= ve
> access to the result-params for the block. The rest of this could then= be a
> separate package easily enough. Would that be a better approach as it = would
> allow the org core to not be so tightly coupled to org-attach?

org-attach is in the Org core. It should not be a problem supporting
org-attach in org babel.

> I'm using magit; I just don't normally restrain myself to the = line length.
> I'll make sure to do that for submitted patches here.

You may find flycheck-mode useful to hint things like line length.

> In terms of this mailing list and overall contribution process, how be= st to
> remedy things for the patch? Just modify it and reply with the modifie= d
> patch as an attachment?

Yep. Just submit the updated patch. Preferably, also add [PATCH] at the
beginning of the message topic. Then, the patch will also be shown in
updates.orgmode.org

Best,
Ihor
--00000000000066482005caf48868--