On 02/11/2025 23:25, Ihor Radchenko wrote:
Max Nikulin writes:
Ihor Radchenko wrote:
When exporting, we will pre-process all the nested links and only the
links that are (a) a sole contents element of the parent link
description; (b) are images.
(b) is inconsistent with generic preview framework where other types of
links (besides images) may define custom overlays. Perhaps :export
function should know whether it called for a nested link, so it should
not generate active link, or it is regular "standalone" link.
Currently, nested links are handled by export via
`org-export-insert-image-links', which makes use of
Thanks, I was not aware that nested links are used already. For some
reason I though every backend tests independently if link description
looks like an image. Likely it is possible to modify the filter so that
3rd party backeds will not notice changes.
`org-export-default-inline-image-rule'
... or a backend specific regexp (.pdf is an image for LaTeX, but not
for HTML).
In any case, :export function might be able to check for nested links if
we pass it a link object, as discussed in another thread about :export.
So, this is not something unsolvable.
So developers of custom export and preview functions should not forget
to handle cases with and without nesting:
[[myimg:id-of-image]]
[[myimg:id-of-image][Some text]]
[[myimg:id-of-full-size-image][<myimg:id-of-thumbnail>]]
and to different outer and inner link types.
I can not estimate consequences for 3rd party packages that invokes
parser to handle user commands. They must be updated to ignore nested
links. I do not know where handling of special cases is more painful.
[...]> Could you think of examples when packages may be broken?
No, I am just speculating about code that getting the inner link instead
of the outer one as an element at point. Another case might be
(org-element-map ast 'link ...)
I do not feel that my objections are strong any more.
