From: Jacob Gerlach <jacobgerlach@gmail.com>
To: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [RFC] [PATCH] Warn about unexpanded macros on export
Date: Wed, 11 Mar 2015 22:55:48 -0400 [thread overview]
Message-ID: <CAA6UvuEPDwjCOG9o1MYxsqk6eUN3muYBqeLRj670FKQ2iAPK8A@mail.gmail.com> (raw)
In-Reply-To: <87zjdkw7jt.fsf@nicolasgoaziou.fr>
[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]
On Sun, Sep 28, 2014 at 3:03 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Aaron Ecay <aaronecay@gmail.com> writes:
>> The links issue (re-)raised by Jacob in
>> <http://mid.gmane.org/CAA6UvuFm-1nWD06A5o3HwSvEQmgqLJNcfK_PtoHSEhcVdJTYQw@mail.gmail.com>
>> 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
[-- Attachment #2: 0001-ox.el-Issue-error-for-unresolved-fuzzy-link.patch --]
[-- Type: text/x-patch, Size: 2255 bytes --]
From 20f84420a84997fc0e15df5af2e65b3cfde87ac1 Mon Sep 17 00:00:00 2001
From: Jacob Gerlach <jacobgerlach@gmail.com>
Date: Wed, 11 Mar 2015 22:39:11 -0400
Subject: [PATCH] ox.el: Issue error for unresolved fuzzy link
* lisp/org-capture.el (org-export-resolve-fuzzy-link): throw error
instead of returning nil when link can't be resolved.
* testing/lisp/test-ox.el (test-org-export/resolve-fuzzy-link): change
last test from should-not to should-error
In addition to throwing an error, don't store the failed match in the
link cache.
TINYCHANGE
---
lisp/ox.el | 7 ++++---
testing/lisp/test-ox.el | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 0c7728f..a28a227 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -4068,7 +4068,7 @@ significant."
;; Last case: link either points to a headline or to nothingness.
;; Try to find the source, with priority given to headlines with
;; the closest common ancestor. If such candidate is found,
- ;; return it, otherwise return nil.
+ ;; return it, otherwise signal an error.
(t
(let ((find-headline
(function
@@ -4094,8 +4094,9 @@ significant."
(org-element-lineage parent-hl nil t))))
(let ((foundp (funcall find-headline path parent)))
(when foundp (throw 'exit foundp))))
- ;; No destination found: return nil.
- (and (not match-title-p) (puthash path nil link-cache))))))))
+ ;; No destination found: error.
+ (unless match-title-p
+ (error (format "Unable to resolve link \"%s\"" raw-path)))))))))
(defun org-export-resolve-id-link (link info)
"Return headline referenced as LINK destination.
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 1b70a78..7cf1e1d 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -2478,8 +2478,8 @@ Another text. (ref:text)
(org-element-type
(org-export-resolve-fuzzy-link
(org-element-map tree 'link 'identity info t) info)))))
- ;; Return nil if no match.
- (should-not
+ ;; Error if no match.
+ (should-error
(org-test-with-parsed-data "[[target]]"
(org-export-resolve-fuzzy-link
(org-element-map tree 'link 'identity info t) info)))
--
1.9.1
next prev parent reply other threads:[~2015-03-12 2:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 19:12 [RFC] [PATCH] Warn about unexpanded macros on export Aaron Ecay
2014-09-19 19:29 ` Nicolas Goaziou
2014-09-23 3:25 ` Aaron Ecay
2014-09-23 16:59 ` Grant Rettke
2014-09-23 17:18 ` Aaron Ecay
2014-09-23 17:29 ` Jacob Gerlach
2014-09-23 21:10 ` Nicolas Goaziou
2014-09-23 20:24 ` Nicolas Goaziou
2014-09-28 3:53 ` Aaron Ecay
2014-09-28 6:59 ` Nicolas Goaziou
2014-10-12 15:48 ` Aaron Ecay
2014-09-23 20:26 ` Rasmus
2014-09-28 4:00 ` Aaron Ecay
2014-09-28 7:03 ` Nicolas Goaziou
2014-10-12 15:49 ` Aaron Ecay
2014-10-12 17:19 ` Nicolas Goaziou
2015-03-12 2:55 ` Jacob Gerlach [this message]
2015-03-15 8:44 ` Nicolas Goaziou
2015-03-17 16:20 ` Jacob Gerlach
2015-03-17 22:38 ` Nicolas Goaziou
2015-03-18 20:25 ` Jacob Gerlach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA6UvuEPDwjCOG9o1MYxsqk6eUN3muYBqeLRj670FKQ2iAPK8A@mail.gmail.com \
--to=jacobgerlach@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).