[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internal link to resulting image from source block
From: |
reza |
Subject: |
Re: Internal link to resulting image from source block |
Date: |
Thu, 4 Aug 2022 17:21:54 +0000 |
On 8/4/22 04:37, Ihor Radchenko wrote:
>
> Nothing really wrong on your side. It is probably an omission on the Org
> sid >
> Executing the above code produces
>
> #+RESULTS: html transformation
> [[file:img/transformation-html.svg]]
>
> However, it is currently impossible to link to such results paragraph by
> itself - only to the parent src block. Since you are using :exports
> results, the export code does not "see" the src block; only the results
> block which cannot be referenced. Hence, the error.
I assumed it was something like this, but thank you for the clarification.
> 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.
Cheers,
Reza
OpenPGP_0xC375C6AF05125C52.asc
Description: application/pgp-keys
OpenPGP_signature
Description: PGP signature
- Internal link to resulting image from source block, reza, 2022/08/03
- Re: Internal link to resulting image from source block, Ihor Radchenko, 2022/08/03
- Message not available
- Re: Internal link to resulting image from source block,
reza <=
- Re: Internal link to resulting image from source block, Ihor Radchenko, 2022/08/04
- Message not available
- Re: Internal link to resulting image from source block, reza, 2022/08/05
- [PATCH] org-export: Make results of named code blocks a valid link, Ihor Radchenko, 2022/08/05
- Message not available
- Re: [PATCH] org-export: Make results of named code blocks a valid link, reza, 2022/08/08
- Re: [PATCH] org-export: Make results of named code blocks a valid link, Ihor Radchenko, 2022/08/08
- Re: [PATCH] org-export: Make results of named code blocks a valid link, Ihor Radchenko, 2022/08/22