Dima Kogan writes: > Hi. I'm using the org included with a very recent emacs built from git. > > I have a large project consisting of many .org files that I'm exporting > to html. Somewhere there's a broken link, so when I export the project I > get > > user-error: Unable to resolve link: "figures/blahblahblah.svg" > > This doesn't tell me where the problem is, specifically, so to find out > I > > (setq debug-on-error t) > > and go again. But something about the org code is preventing the > debugger from triggering on this. That really shouldn't be happening. > This is an error that's causing the export to give up and quit, and the > debugger should come up (when debug-on-error).
It's not Org specific; it's a default behavioral difference between error and user-error: ,----[ C-h f user-error RET ] | [...] | In contrast with other errors, user errors normally do not cause | entry to the debugger, even when ‘debug-on-error’ is non-nil. | This can be overridden by ‘debug-ignored-errors’. `---- > Also, it would be nice if the error message reported the source file and > line number of the bad link. That does sound helpful. Completely guessing, but I would think the source file but not the line number may be easily obtainable when the org-link-broken error (later converted to a user-error) is signaled. You may find setting org-export-with-broken-links to `mark' helpful for locating the broken links, though it marks the broken links in the output, so the results still need to be mapped back to the corresponding source file.
