Updated patch; fixed typos and wrapped the commit message to 72 characters

Thinking about the input files issue some more, I wonder if an attach keyword wouldn't better function as setting the working directory to the node's attachment directory and then fixing up any inserted link to use "attachment:" if it's relative to that.

I've been working with this for a bit in my own workflow and it's been useful, but I'll see about maybe experimenting with some other approaches as well. Moving the referenced file to the attachment directory never felt completely right to me.

On Wed, Sep 1, 2021 at 1:01 PM Ryan Scott <ryan@vicarious-living.com> wrote:

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