Ihor Radchenko <yantar92@gmail.com> writes:

> Michael Dauer <mick.dauer@gmail.com> writes:
>
>> Shouldn't be org-export-resolve-fuzzy-link the relevant function, at least
>> for my use case?
>>
>> But there it looks like it is searching through all elements including
>> inlinetasks, which is in org-element-all-elements:
>> (append pseudo-types '(target) org-element-all-elements)
>
> Maybe. Further it also calls org-export-search-cells, which does not
> consider inlinetasks even if they are matched.

I have investigated further.
In addition to inlinetasks not being taken into account by
`org-export-search-cells', `org-export-resolve-fuzzy-link', and
`org-export-resolve-id-link', there is no export backend support for
linking inlinetasks.

In order to have full support for inlinetasks during export, we need to
modify export backends to be able to link to the inlinetasks.

For example,
- ox-html.el does not associate ID anchor in
  `org-html-format-inlinetask-default-function'
- ox-latex.el also does not provide any label in
  `org-latex-format-inlinetask-default-function'
- ox-ascii.el does not assign a number to be referred to in
  `org-ascii-format-inlinetask-default'

I did not check other backends.

Note that changing only ox.el without altering the individual backends
can break export in unexpected ways.

I am attaching a simple patch changing the generic link resolution
machinery. If one applies the patch, **export will be broken**.
In particular, exporting to ASCII (C-c C-e t U) will straight throw
an error.

The same may happen in third-party export backends even if we alter the
all built-in export backends appropriately.

Thus, supporting links to inlinetasks will be a breaking change and such
support should be shielded behind a user customization, not be enabled
by default.