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 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 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 >> >