From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: org-capture in message-mode buffer Date: Tue, 24 May 2011 13:38:04 +0200 Message-ID: <14FE40C9-9E73-4209-8A72-076F7373827D@gmail.com> References: <17DB4712-0BB8-4322-8CBF-368FDFD19222@gmail.com> <87oc2speid.fsf@member.fsf.org> <87k4dgpdgx.fsf@member.fsf.org> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:57015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOpw8-0007Te-2D for emacs-orgmode@gnu.org; Tue, 24 May 2011 07:38:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOpw7-0003K5-5x for emacs-orgmode@gnu.org; Tue, 24 May 2011 07:38:08 -0400 Received: from mail-ey0-f169.google.com ([209.85.215.169]:45440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOpw6-0003K0-VN for emacs-orgmode@gnu.org; Tue, 24 May 2011 07:38:07 -0400 Received: by eyd9 with SMTP id 9so2456181eyd.0 for ; Tue, 24 May 2011 04:38:06 -0700 (PDT) In-Reply-To: <87k4dgpdgx.fsf@member.fsf.org> 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: Tassilo Horn Cc: emacs-orgmode@gnu.org On May 24, 2011, at 1:35 PM, Tassilo Horn wrote: > 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. I agree. > > 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. Thanks! - Carsten > > 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--- - Carsten