Jacob Gerlach <jacobgerl...@gmail.com> 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,
