emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jacob Gerlach <jacobgerlach@gmail.com>
To: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [RFC] [PATCH] Warn about unexpanded macros on export
Date: Tue, 17 Mar 2015 12:20:28 -0400	[thread overview]
Message-ID: <CAA6UvuEqH+FtBBhGe+a_pSK-qSVce4=cEkjqjz1oQdDnALvuXw@mail.gmail.com> (raw)
In-Reply-To: <8761a23b0i.fsf@nicolasgoaziou.fr>

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

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

[-- Attachment #2: 0001-ox.el-Issue-error-for-unresolved-fuzzy-link.patch --]
[-- Type: text/x-patch, Size: 2550 bytes --]

From a9221500b721a501f7b7f05519dfc0d6f30f23d0 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/ox.el (org-export-resolve-fuzzy-link): Throw an 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              | 8 ++++----
 testing/lisp/test-ox.el | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 0c7728f..9461117 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -4021,7 +4021,7 @@ Return value can be an object, an element, or nil:
   will be given to the one with the closest common ancestor, if
   any, or the first one in the parse tree otherwise.
 
-- Otherwise, return nil.
+- Otherwise, report an error.
 
 Assume LINK type is \"fuzzy\".  White spaces are not
 significant."
@@ -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,8 @@ 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.
+	    (user-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


  reply	other threads:[~2015-03-17 16:20 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
2015-03-15  8:44             ` Nicolas Goaziou
2015-03-17 16:20               ` Jacob Gerlach [this message]
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='CAA6UvuEqH+FtBBhGe+a_pSK-qSVce4=cEkjqjz1oQdDnALvuXw@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).