On Sun, Sep 28, 2014 at 3:03 AM, Nicolas Goaziou wrote: > Aaron Ecay writes: >> The links issue (re-)raised by Jacob in >> >> is a bit harder to deal with, since each backend currently does >> something a little different. It would be possible to make every >> backend’s org-X-link function error out at the end, but I’m not sure >> if that’s the right thing to do or not. > > A more workable solution would be to focus on internal links only and > patch `org-export-resolve-id-link', `org-export-resolve-fuzzy-link', > `org-export-resolve-coderef' (not needed for radio links). Patch attached for fuzzy links. I don't really use code blocks, so I wasn't sure what to do with org-export-resolve-coderef. Should the final (when (re-search... (cond ... become (or (re-search... (cond ... (error ID links are tricky. AFAICT, an invalid id link will always resolve to the file it's contained in. The last check in org-export-resolve-id-link is looking for the id in `:id-alist'. Is this the same `:id-alist' built in org-export-get-environment? If so, is it desirable for org-id-find-id-file to fall back on the current buffer (the current behavior)? It seems like this will mistakenly cause org-export-get-environment to think that the bad link is valid and pointing to an "external" file. IIUC, the fall back behavior doesn't occur inside org-test-with-parsed-data because buffer-file-name returns nil. I don't know the implications of changing org-id-find-id-file. The fall back behavior was introduced in ac83bc01 when org-id was mostly rewritten. Removing the fall back behavior doesn't cause any failures on `make test'. If it's acceptable to remove the fall back, I can provide a similar patch for org-export-resolve-id-link. Example, foo.org: [[id:points-nowhere]] [[id:this-one-too][also bad]] Exports (latex) to: \url{foo.org} \href{foo.org}{also bad} Regards, Jake