Re: New source block results option for attaching file to node

[Ryan Scott]

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 <yantar92@gmail.com> wrote:

Ryan Scott <ryan@vicarious-living.com> 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