From: Ihor Radchenko <yantar92@gmail.com>
To: reza <reza@housseini.me>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: [PATCH] org-export: Make results of named code blocks a valid link
Date: Fri, 05 Aug 2022 18:15:43 +0800 [thread overview]
Message-ID: <87mtcjnghc.fsf@localhost> (raw)
In-Reply-To: <010201826cb68597-bf75d596-7890-4dd0-b9ff-0c7b617b4dd4-000000@eu-west-1.amazonses.com>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
reza <reza@housseini.me> writes:
> On 8/5/22 03:48, Ihor Radchenko wrote:
>>
>> This email is already a bug report :)
> Haha nice :)
>>
>> However, we cannot just blindly carry over the name tag to the result.
>>
>> Consider a case when you have ":results both" in your src block. Where
>> should the [[html transformation]] link refer to? The src block? The
>> resulting image?
>>
> Perhaps it is sufficient to add a hint to the error message:
>
> unable to resolve link, name tag is on source but you specified :exports
> results
This would be tricky. The export code is only presented with buffer
version to be exported. All the :exports none/:exports results code
blocks are removed when we resolve links.
> Or just carry it over for :exports results only?
I like this idea better. See the attached patch.
After the patch, links to :exports both blocks will be ambiguous, unless
the results are explicitly named. So, I documented this detail in the
manual.
Let me know if there are any objections.
Best,
Ihor
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-export-Make-results-of-named-code-blocks-a-valid.patch --]
[-- Type: text/x-patch, Size: 4093 bytes --]
From 0a0dda33cee7355602feb954e0645ed8652e0983 Mon Sep 17 00:00:00 2001
Message-Id: <0a0dda33cee7355602feb954e0645ed8652e0983.1659694297.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@gmail.com>
Date: Fri, 5 Aug 2022 18:09:02 +0800
Subject: [PATCH] org-export: Make results of named code blocks a valid link
target
* lisp/ox.el (org-export-search-cells): Use #+RESULTS keyword as
search cell when #+NAME is not provided. Update the docstring
accordingly.
(org-export-resolve-fuzzy-link): Update the docstring.
* doc/org-manual.org (Exporting Code Blocks): Document the new
behavior and explain the details of exporting links to named code
blocks/results.
Fixes https://orgmode.org/list/010201826cb68597-bf75d596-7890-4dd0-b9ff-0c7b617b4dd4-000000@eu-west-1.amazonses.com
---
doc/org-manual.org | 30 ++++++++++++++++++++++++++++++
lisp/ox.el | 10 ++++++----
2 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 466718e6e..e03fd059a 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18283,6 +18283,36 @@ ** Exporting Code Blocks
exported file. Whether the code is evaluated at all depends on
other options. Example: =:exports none=.
+If a source block is named using =NAME= keyword, the same name will be
+assigned to the results of evaluation. This way, fuzzy links pointing
+to the named source blocks exported using =:exports results= will
+remain valid and point to the results of evaluation.
+
+Results of evaluation of a named block can also be explicitly named
+using a separate =NAME= keyword. The name value set via =NAME=
+keyword will be preferred over the parent source block.
+
+: #+NAME: code name
+: #+BEGIN_SRC emacs-lisp :exports both value
+: (+ 1 2)
+: #+END_SRC
+:
+: #+NAME: results name
+: #+RESULTS: code name
+: 3
+:
+: This [[code name][link]] will point to the code block.
+: Another [[results name][link]] will point to the results.
+
+Explicit setting of the result name may be necessary when a named code
+block is exported using =:exports both=. Links to such block may
+arbitrarily point either to the code block or to its results when
+results do not have a distinct name.
+
+Note that all the links pointing to a source block exported using
+=:exports none= will be broken. This will make export process fail,
+unless broken links are allowed during export (see [[*Export Settings]]).
+
#+vindex: org-export-use-babel
To stop Org from evaluating code blocks to speed exports, use the
header argument =:eval never-export= (see [[*Evaluating Code Blocks]]).
diff --git a/lisp/ox.el b/lisp/ox.el
index 57d375b35..433272915 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -4312,7 +4312,7 @@ (defun org-export-search-cells (datum)
- target's or radio-target's name as a list of strings if
TYPE is `target'.
- - NAME affiliated keyword if TYPE is `other'.
+ - NAME or RESULTS affiliated keyword if TYPE is `other'.
A search cell is the internal representation of a fuzzy link. It
ignores white spaces and statistics cookies, if applicable."
@@ -4330,7 +4330,8 @@ (defun org-export-search-cells (datum)
(and custom-id (cons 'custom-id custom-id)))))))
(`target
(list (cons 'target (split-string (org-element-property :value datum)))))
- ((and (let name (org-element-property :name datum))
+ ((and (let name (or (org-element-property :name datum)
+ (car (org-element-property :results datum))))
(guard name))
(list (cons 'other (split-string name))))
(_ nil)))
@@ -4362,8 +4363,9 @@ (defun org-export-resolve-fuzzy-link (link info &rest pseudo-types)
- If LINK path matches a target object (i.e. <<path>>) return it.
-- If LINK path exactly matches the name affiliated keyword
- (i.e. #+NAME: path) of an element, return that element.
+- If LINK path exactly matches the name or results affiliated keyword
+ (i.e. #+NAME: path or #+RESULTS: name) of an element, return that
+ element.
- If LINK path exactly matches any headline name, return that
element.
--
2.35.1
next prev parent reply other threads:[~2022-08-05 10:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <56e1e299-b04d-0b01-7dec-564207d4484a@housseini.me>
2022-08-03 21:13 ` Internal link to resulting image from source block reza
2022-08-04 2:37 ` Ihor Radchenko
[not found] ` <032306dd-7465-fdfd-b6c1-0bd82b662370@housseini.me>
2022-08-04 17:21 ` reza
2022-08-05 1:48 ` Ihor Radchenko
[not found] ` <cb227c57-2e08-78d5-f1b4-e70d0c58bf16@housseini.me>
2022-08-05 6:34 ` reza
2022-08-05 10:15 ` Ihor Radchenko [this message]
[not found] ` <2af7a860-bb5f-a639-291a-ba7f7d38aa20@housseini.me>
2022-08-08 10:59 ` [PATCH] org-export: Make results of named code blocks a valid link reza
2022-08-08 12:21 ` Ihor Radchenko
2022-08-22 12:01 ` 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=87mtcjnghc.fsf@localhost \
--to=yantar92@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=reza@housseini.me \
/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).