From: Ryan Scott <ryan@vicarious-living.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode@gnu.org, Timothy <tecosaur@gmail.com>
Subject: [PATCH] Re: New source block results option for attaching file to node
Date: Thu, 2 Sep 2021 00:40:14 -0700 [thread overview]
Message-ID: <CAHBUXNwLuQ4wZiZc8MLDX8BemLmjoLOoxAHGvY4vKSG64ADGVA@mail.gmail.com> (raw)
In-Reply-To: <CAHBUXNxTRPQC2ZKFxpnMpM6PCuhppu+Xjo3NJY8bEEOs4VdJCQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3792 bytes --]
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
>>
>
[-- Attachment #1.2: Type: text/html, Size: 4900 bytes --]
[-- Attachment #2: 0001-ob-core-Added-option-for-attaching-file-from-babel-s.patch --]
[-- Type: application/octet-stream, Size: 4922 bytes --]
From cbe97587df4b660f56e420015222e4f3559588a2 Mon Sep 17 00:00:00 2001
From: "Ryan C. Scott" <ryan@5pmcasual.com>
Date: Wed, 25 Aug 2021 02:15:09 -0700
Subject: [PATCH] ob-core: Added option for attaching file from babel
src block result
* ob-core.el (org-babel-format-result): Added `:results-param' option
`attach' which when used with `file' will cause the resultant file path
to be moved to the `org-attach-dir' for the node.
(org-babel-result-to-file): Added optional 3rd parameter `type' which
will be used in place of "file" in link type, if present.
(org-babel-result-to-file-attachment): New function that moves the file
at the provided `result' path to the nodes attachment directory,
creating it as necessary using `org-attach-dir'. A new function was
created to adhere to the design of the API and not complicated
`org-babel-result-to-file' with the movement to the attachment
directory.
* org-attach.el (org-attach-dir): Added autoload header to simplify
dependencies necessary to support this feature (called in
`org-babel-result-to-file-attachment').
---
lisp/ob-core.el | 31 ++++++++++++++++++++++++++-----
lisp/org-attach.el | 1 +
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 857e03e55..c1d1b77e0 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2188,6 +2188,10 @@ silent -- no results are inserted into the Org buffer but
file ---- the results are interpreted as a file path, and are
inserted into the buffer using the Org file syntax.
+attach -- used with `file', will move the file at the path returned
+ by the source block to the nodes attachment directory (as
+ reported by `org-attach-dir'.
+
list ---- the results are interpreted as an Org list.
raw ----- results are added directly to the Org file. This is
@@ -2241,9 +2245,13 @@ INFO may provide the values of these header arguments (in the
(cond ((stringp result)
(setq result (org-no-properties result))
(when (member "file" result-params)
- (setq result (org-babel-result-to-file
- result
- (org-babel--file-desc (nth 2 info) result)))))
+ (setq result (if (member "attach" result-params)
+ (org-babel-result-to-file-attachment
+ result
+ (org-babel--file-desc (nth 2 info) result))
+ (org-babel-result-to-file
+ result
+ (org-babel--file-desc (nth 2 info) result))))))
((listp result))
(t (setq result (format "%S" result))))
(if (and result-params (member "silent" result-params))
@@ -2548,7 +2556,7 @@ in the buffer."
(line-beginning-position 2))
(point))))))
-(defun org-babel-result-to-file (result &optional description)
+(defun org-babel-result-to-file (result &optional description type)
"Convert RESULT into an Org link with optional DESCRIPTION.
If the `default-directory' is different from the containing
file's directory then expand relative links."
@@ -2559,7 +2567,8 @@ file's directory then expand relative links."
(expand-file-name
(file-name-directory
(buffer-file-name (buffer-base-buffer)))))))))
- (format "[[file:%s]%s]"
+ (format "[[%s:%s]%s]"
+ (or type "file")
(if (and default-directory
(buffer-file-name (buffer-base-buffer)) same-directory?)
(if (eq org-link-file-path-type 'adaptive)
@@ -2571,6 +2580,18 @@ file's directory then expand relative links."
result)
(if description (concat "[" description "]") "")))))
+(defun org-babel-result-to-file-attachment (result &optional description)
+ "Convert RESULT into an Org link after moving the provided path to the current node's attachment directory as reported by `org-attach-dir', using the optional DESCRIPTION if provided.
+See `org-babel-result-to-file' for further link generation details."
+
+ (let* ((dir (file-relative-name
+ (org-attach-dir t)))
+ (filename (file-name-nondirectory result))
+ (newname (format "%s/%s" dir filename)))
+
+ (rename-file result newname t)
+ (org-babel-result-to-file filename description "attachment")))
+
(defun org-babel-examplify-region (beg end &optional results-switches inline)
"Comment out region using the inline `==' or `: ' org example quote."
(interactive "*r")
diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index e8e8ade83..9f180255a 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -323,6 +323,7 @@ Shows a list of commands and prompts for another key to execute a command."
(call-interactively command)
(error "No such attachment command: %c" c))))))
+;;;###autoload
(defun org-attach-dir (&optional create-if-not-exists-p no-fs-check)
"Return the directory associated with the current outline node.
First check for DIR property, then ID property.
--
2.32.0.windows.2
next prev parent reply other threads:[~2021-09-02 7:41 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-26 8:48 New source block results option for attaching file to node Ryan Scott
2021-08-31 11:15 ` Timothy
2021-08-31 19:43 ` Ryan Scott
2021-09-01 14:45 ` Ihor Radchenko
2021-09-01 20:01 ` Ryan Scott
2021-09-02 7:40 ` Ryan Scott [this message]
2021-09-02 13:44 ` [PATCH] " Greg Minshall
2021-09-03 3:10 ` Ihor Radchenko
2021-09-03 3:28 ` Ryan Scott
2021-09-05 13:22 ` Ihor Radchenko
2021-09-05 13:56 ` Ryan Scott
2021-09-10 1:04 ` Ryan Scott
2021-09-10 6:26 ` Timothy
2021-10-02 8:32 ` Ihor Radchenko
2021-10-02 9:39 ` Ryan Scott
2021-10-05 0:04 ` Christopher M. Miles
2021-10-05 1:05 ` Ryan Scott
2021-10-08 1:22 ` Christopher M. Miles
2021-11-05 7:16 ` Ryan Scott
2022-04-21 12:47 ` Ihor Radchenko
2022-04-21 17:29 ` Ryan Scott
2022-04-22 6:02 ` Ihor Radchenko
2022-04-22 6:19 ` Ryan Scott
2022-06-10 8:06 ` Ryan Scott
2022-06-11 4:32 ` Ihor Radchenko
2022-06-11 7:47 ` Ryan Scott
2022-06-11 12:49 ` Ihor Radchenko
2022-06-12 0:47 ` Ryan Scott
2022-06-14 4:11 ` Ihor Radchenko
2022-06-14 5:55 ` Ryan Scott
2022-06-14 9:04 ` Ryan Scott
2022-06-14 13:48 ` Ihor Radchenko
2022-06-14 18:23 ` Ryan Scott
2022-06-11 12:51 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHBUXNwLuQ4wZiZc8MLDX8BemLmjoLOoxAHGvY4vKSG64ADGVA@mail.gmail.com \
--to=ryan@vicarious-living.com \
--cc=emacs-orgmode@gnu.org \
--cc=tecosaur@gmail.com \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).