emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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

Let me know if there are any objections.


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

* lisp/ox.el (org-export-search-cells): Use #+RESULTS keyword as
search cell when #+NAME is not provided.  Update the docstring
(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

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

  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:

  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 \


* 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


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