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

[Ryan Scott <ryan@vicarious-living.com>]

[-- Attachment #1: Type: text/plain, Size: 3040 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3832 bytes --]