Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Nicolas Goaziou]

Jacob Gerlach <address@hidden> writes:

> I tried this, or more specifically:
> (or ((org-element-map
> ...
>     info 'first-match))
>   (user-error ...
>  and got a failure on test-org-export/resolve-coderef. It's not
> obvious to me from reading the tests if there is a test that needs to
> be changed, or if it's a legitimate failure and a different approach
> is needed (or if I made a mistake). I asked in [1] for some guidance
> on tests, and I'm still lost.

There is a spurious (...) in the code above.

I implemented it in a886b234763f288670103d2c98169164dedec06c.

>> According to its docstring, `org-id-find-id-file' returns nil when
>> search failed. Isn't it the case?
> Are you looking at `org-id-find-id-in-file' rather than
> `org-id-find-id-file'? The docstring for `org-id-find-file' only says:
> "Query the id database for the file in which this ID is located."

You're right.

>> `org-export-resolve-id-link' could throw an error, indeed.
> I'm not clear on the way forward for id links. I propose removing the
> fall back behavior in `org-id-find-id-file'. If that's acceptable, I
> can provide a patch for `org-export-resolve-id-link'.

Actually, we don't even need to do that. I changed "ox.el" so it uses
`org-id-find' instead of `org-id-find-id-file'. The former has a better
fall-back value. See

  e0b19dedb99d3c01199a159a2da8f9aa4adb2f6f

> Updated fuzzy link patch attached.

Applied (with minor tweaks). Thank you.


Regards,