reza <r...@housseini.me> writes: > Hi List > > I'm exporting a plantuml figure to HTML like > > #+name: html transformation > #+begin_src plantuml :file img/transformation-html.svg :exports results > file org > file html > org -> html : org-html-publish-to-html > #+end_src > > Now I want to include an internal link to this figure with ~[[html > transformation]]~ but when I export I always get "Unable to resolve > link". Any idea what I'm doing wrong?
Nothing really wrong on your side. It is probably an omission on the Org side. 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. 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. Best, Ihor