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 <yanta...@gmail.com> wrote: > Ryan Scott <r...@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 >
