From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tassilo Horn Subject: Re: org-capture in message-mode buffer Date: Tue, 24 May 2011 13:35:14 +0200 Message-ID: <87k4dgpdgx.fsf@member.fsf.org> References: <17DB4712-0BB8-4322-8CBF-368FDFD19222@gmail.com> <87oc2speid.fsf@member.fsf.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:58318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOptM-0006x1-Ap for emacs-orgmode@gnu.org; Tue, 24 May 2011 07:35:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOptL-0002kc-97 for emacs-orgmode@gnu.org; Tue, 24 May 2011 07:35:16 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:44688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOptL-0002kT-1E for emacs-orgmode@gnu.org; Tue, 24 May 2011 07:35:15 -0400 In-Reply-To: (Carsten Dominik's message of "Tue, 24 May 2011 12:56:00 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: emacs-orgmode@gnu.org Carsten Dominik writes: >> Basically, there should be a possibility to let the link creator >> functions return "yes, I was the right handler, but because of reason X, >> I couldn't create a link". Is there something like that? > > What happens if you return t in this case, without calling > org-store-link-props ? Then no link will be created. Basically, that's what we'd like to have. But somehow my `called-interactively-p' check now always returns nil. I'm pretty sure it didn't when I tested my last patch. But according to its docs, the current behavior is correct. It should only check if the *containing* function was called interactively, not if its caller was called interactively. So I'd say the current behavior, i.e., erroring if there's no Gcc header, is correct and neither one of the two proposed patches shall be applied. Instead of making the low-level functions aware of their call context (an interactive org-store-link call called org-gnus-store-link vs. an interactive org-capture called org-store-link that in turn called org-gnus-store-link), the caller should be adapted to handle the error appropriately. Here's a patch for the `org-capture' use case. I've tested it. In a message buffer without Gcc header, calling `org-store-link' will produce an error indicating the problem to the user. When called by `org-capture', the error is still produce but simply ignored so you still can capture. In that case, the %a format spec is empty. Bye, Tassilo --8<---------------cut here---------------start------------->8--- >From dbee3ff4f0a6584c4437af8ebff285babc87db30 Mon Sep 17 00:00:00 2001 From: Tassilo Horn Date: Tue, 24 May 2011 13:29:53 +0200 Subject: [PATCH 3/3] Ignore errors from link creation. 2011-05-24 Tassilo Horn * org-capture.el (org-capture): Ignore errors from link creation. --- lisp/org-capture.el | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 0af4529..ccfca75 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -415,7 +415,7 @@ bypassed." (annotation (if (and (boundp 'org-capture-link-is-already-stored) org-capture-link-is-already-stored) (plist-get org-store-link-plist :annotation) - (org-store-link nil))) + (ignore-errors (org-store-link nil)))) (initial (and (org-region-active-p) (buffer-substring (point) (mark)))) (entry (org-capture-select-template keys))) -- 1.7.5.rc3 --8<---------------cut here---------------end--------------->8---