From: Ihor Radchenko <yantar92@gmail.com>
To: reza <reza@housseini.me>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: Internal link to resulting image from source block
Date: Fri, 05 Aug 2022 09:48:37 +0800 [thread overview]
Message-ID: <87bkszpiiy.fsf@localhost> (raw)
In-Reply-To: <0102018269e0c5a8-804eb3c2-47b4-45e5-9efc-87a2aa56cc0e-000000@eu-west-1.amazonses.com>
reza <reza@housseini.me> writes:
>> They way to work around the problem is providing explicit name anchor to
>> the results block:
>>
>> ------------
>> #+name: html transformation
>> #+begin_src plantuml :file img/transformation-html.svg :exports results :mkdirp yes
>> file org
>> file html
>> org -> html : org-html-publish-to-html
>> #+end_src
>>
>> #+name: html transformation result
>> #+RESULTS: html transformation
>> [[file:img/transformation-html.svg]]
>>
>> Now I want to include an internal link to this figure with [[html
>> transformation result]]. This works now.
>> ------------
>>
>> Though I do agree that the current behaviour is not intuitive in this
>> specific scenario. When a user provides :exports results, it would make
>> sense to inherit all the affiliated keywords, including #+name and
>> possibly various #+attr_* to the results of evaluation.
>>
>> On the other hand, inheriting may be tricky. I can imagine situations
>> when such inheritance is not desired and a user actually prefers to
>> state the results keywords manually.
>>
>> I am not sure what would be the best way to handle the situation at hand
>> while not breaking the other :exports variants.
>
> Shall I file a bug report? As a beginner I assumed that the name tag
> gets carried over to the result and I still think it is a sensible
> solution, but I could imagine that is perhaps not a very explicit behavior.
This email is already a bug report :)
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?
Best,
Ihor
next prev parent reply other threads:[~2022-08-05 1:48 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 [this message]
[not found] ` <cb227c57-2e08-78d5-f1b4-e70d0c58bf16@housseini.me>
2022-08-05 6:34 ` reza
2022-08-05 10:15 ` [PATCH] org-export: Make results of named code blocks a valid link Ihor Radchenko
[not found] ` <2af7a860-bb5f-a639-291a-ba7f7d38aa20@housseini.me>
2022-08-08 10:59 ` 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=87bkszpiiy.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).