Hello,

Thanks for the feedback.

On Sun, Mar 15, 2015 at 4:44 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>> I don't really use code blocks, so I wasn't sure what to do with
>> org-export-resolve-coderef.
[...]
> No, the whole body could be wrapped with an `or':
>
>   (or (org-element-map ...)
>       (user-error "Unable to resolve code reference: %s" ref))
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.

>> If so, is it desirable for org-id-find-id-file to fall back on the
>> current buffer (the current behavior)?
>
> 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."

[...]
> `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'.

>> Subject: [PATCH] ox.el: Issue error for unresolved fuzzy link
[...]
Commit message fixed. I also updated the docstring for
org-export-resolve-fuzzy link.
>> +       ;; No destination found: error.
>> +       (unless match-title-p
>> +         (error (format "Unable to resolve link \"%s\"" raw-path)))))))))
>
> You don't need to check `match-title-p' here. Also, it should be
> `user-error' instead of `error'.
OK.

Updated fuzzy link patch attached.

Regards,
Jake

[1] http://thread.gmane.org/gmane.emacs.orgmode/96017