org-capture in message-mode buffer

org-capture in message-mode buffer

[Leo]

Hello,

I am running orgmode from git 2011-04-29 on Emacs 23.3.50.

In a message mode buffer, M-x org-capture to get the following error:

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (error "Can not create link: No Gcc header found.")
  signal(error ("Can not create link: No Gcc header found."))
  error("Can not create link: No Gcc header found.")
  org-gnus-store-link()
  run-hook-with-args-until-success(org-gnus-store-link)
  org-store-link(nil)
  org-capture(nil)
  call-interactively(org-capture nil nil)
--8<---------------cut here---------------end--------------->8---

Leo

Re: org-capture in message-mode buffer

[Ulf Stegemann]

Leo <sdl.web@gmail.com> wrote:

> I am running orgmode from git 2011-04-29 on Emacs 23.3.50.
>
> In a message mode buffer, M-x org-capture to get the following error:
>
> Debugger entered--Lisp error: (error "Can not create link: No Gcc header found.")
>   signal(error ("Can not create link: No Gcc header found."))
>   error("Can not create link: No Gcc header found.")
>   org-gnus-store-link()
>   run-hook-with-args-until-success(org-gnus-store-link)
>   org-store-link(nil)
>   org-capture(nil)
>   call-interactively(org-capture nil nil)

The idea behind `org-store-link' (which is triggered by `org-capture')
in message mode is to store a link to a /sent/ message even though the
message has not been sent by the time you call `org-store-link'.  This
currently works only with Gnus and only if there's a Gcc header present
in the message you are working on.  `org-gnus-store-link' needs the Gcc
header to determine where the message would go once it has been sent (in
order to create a link to it).  The error you've encountered means that
there hasn't been a Gcc header in your message when you've called
`org-capture'.

Ulf

Re: org-capture in message-mode buffer

[Leo]

On 2011-05-04 21:14 +0800, Ulf Stegemann wrote:
> The idea behind `org-store-link' (which is triggered by `org-capture')
> in message mode is to store a link to a /sent/ message even though the
> message has not been sent by the time you call `org-store-link'.  This
> currently works only with Gnus and only if there's a Gcc header present
> in the message you are working on.  `org-gnus-store-link' needs the Gcc
> header to determine where the message would go once it has been sent (in
> order to create a link to it).  The error you've encountered means that
> there hasn't been a Gcc header in your message when you've called
> `org-capture'.

I think org-gnus-store-link is too aggressive. I also dislike the fact
that it inserts the Message-Id header.

Also, the stored link may be useless unless it is referenced in the
template chosen by the user.

Leo

Re: org-capture in message-mode buffer

[Ulf Stegemann]

Leo <sdl.web@gmail.com> wrote:

> On 2011-05-04 21:14 +0800, Ulf Stegemann wrote:
>> The idea behind `org-store-link' (which is triggered by `org-capture')
>> in message mode is to store a link to a /sent/ message even though the
>> message has not been sent by the time you call `org-store-link'.  This
>> currently works only with Gnus and only if there's a Gcc header present
>> in the message you are working on.  `org-gnus-store-link' needs the Gcc
>> header to determine where the message would go once it has been sent (in
>> order to create a link to it).  The error you've encountered means that
>> there hasn't been a Gcc header in your message when you've called
>> `org-capture'.
>
> I think org-gnus-store-link is too aggressive.

Hmmm, is it? Suppose that linking to a message yet to be archived
wouldn't be there, then `org-store-link' will tell you `org-store-link:
Cannot link to a buffer which is not visiting a file' when called in a
message buffer (like in any other non-file buffer).

> I also dislike the fact that it inserts the Message-Id header.

As the org link to Gnus messages consists of the group and the message
id the latter one is need (as is the first one, the Gcc header).  No
reliable message id, no org link.  One may argue if it's a good idea to
generate the message id when calling `org-store-link' but I think it's a
fair tradeoff to accept this in order to get the link to the message yet
to be archived.

> Also, the stored link may be useless unless it is referenced in the
> template chosen by the user.

Hmmm, I'm not quite sure what your scenario is here.  If you dislike the
behaviour of `org-store-link' in message mode and furthermore do not
want to store a link at all since your template does not use it, why do
you call `org-capture' from the message mode buffer at all?

Ulf

Re: org-capture in message-mode buffer

[Leo]

On 2011-05-05 15:02 +0800, Ulf Stegemann wrote:
> Hmmm, is it? Suppose that linking to a message yet to be archived
> wouldn't be there, then `org-store-link' will tell you `org-store-link:
> Cannot link to a buffer which is not visiting a file' when called in a
> message buffer (like in any other non-file buffer).

When I call org-capture in any buffer not visiting any file except in
message mode, I don't get any error.

>> I also dislike the fact that it inserts the Message-Id header.
>
> As the org link to Gnus messages consists of the group and the message
> id the latter one is need (as is the first one, the Gcc header).  No
> reliable message id, no org link.  One may argue if it's a good idea to
> generate the message id when calling `org-store-link' but I think it's a
> fair tradeoff to accept this in order to get the link to the message yet
> to be archived.

If that depends on the Gcc header being available, it should check it
and do nothing when users does not use one.

>> Also, the stored link may be useless unless it is referenced in the
>> template chosen by the user.
>
> Hmmm, I'm not quite sure what your scenario is here.  If you dislike the
> behaviour of `org-store-link' in message mode and furthermore do not
> want to store a link at all since your template does not use it, why do
> you call `org-capture' from the message mode buffer at all?
>
> Ulf

That seems like a very strange question. The only reason to have a
global keybinding to org-capture is so that one can invoke it anywhere
anytime. For example, while composing a new mail I might have a great
idea I want to add to my Notes but I don't care where I invoke
org-capture as illustrated by the template I use:

 ("n" "Notes" entry (file "Notes.org") "* %?\n  %i" :prepend t)

BTW, the reason I have stopped using Gcc (long ago) is that I have gmail
to do archiving for me. It is accessible anytime anywhere and not tied
to a specific machine.

I believe the following patch is due.

Leo

diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index eba4cb44..7290f1c6 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -187,7 +187,8 @@ (defun org-gnus-store-link ()
 		  group	newsgroups message-id x-no-archive))
       (org-add-link-props :link link :description desc)
       link))
-   ((eq major-mode 'message-mode)
+   ((and (eq major-mode 'message-mode)
+	 (message-fetch-field "gcc"))
     (setq org-store-link-plist nil)  ; reset
     (save-excursion
       (save-restriction

Re: org-capture in message-mode buffer

[Leo]

On 2011-05-05 15:59 +0800, Leo wrote:
> I believe the following patch is due.

Think about it some more, there is a reason to signal an error when
calling org-store-link interactively but it should not when invoked by
org-capture. Otherwise it will get in the way.

Leo

Re: org-capture in message-mode buffer

[Ulf Stegemann]

Leo <sdl.web@gmail.com> wrote:

> On 2011-05-05 15:02 +0800, Ulf Stegemann wrote:
>> Hmmm, is it? Suppose that linking to a message yet to be archived
>> wouldn't be there, then `org-store-link' will tell you `org-store-link:
>> Cannot link to a buffer which is not visiting a file' when called in a
>> message buffer (like in any other non-file buffer).
>
> When I call org-capture in any buffer not visiting any file except in
> message mode, I don't get any error.

I see.  That seems to be the very real problem, no?

>>> I also dislike the fact that it inserts the Message-Id header.
>>
>> As the org link to Gnus messages consists of the group and the message
>> id the latter one is need (as is the first one, the Gcc header).  No
>> reliable message id, no org link.  One may argue if it's a good idea to
>> generate the message id when calling `org-store-link' but I think it's a
>> fair tradeoff to accept this in order to get the link to the message yet
>> to be archived.
>
> If that depends on the Gcc header being available, it should check it
> and do nothing when users does not use one.

We are really talking about `org-gnus-store-link' here.  The whole
purpose of that function is to create an org link.  I do not agree that
this function should silently do nothing when there's no Gcc header
present.  If the function fails to do what it is meant to do, it should
throw an error.

Another story is if `org-capture' should fail only because
`org-gnus-store-link' (which it called) fails.  There are pros and cons.
I agree that it may be annoying to not be able to org-capture something
from within a message buffer.  OTOH, there may be scenarios where an
error message is helpful because you otherwise would think you've
created a link with your capture but in fact haven't.

>>> Also, the stored link may be useless unless it is referenced in the
>>> template chosen by the user.
>>
>> Hmmm, I'm not quite sure what your scenario is here.  If you dislike the
>> behaviour of `org-store-link' in message mode and furthermore do not
>> want to store a link at all since your template does not use it, why do
>> you call `org-capture' from the message mode buffer at all?
>
> That seems like a very strange question. The only reason to have a
> global keybinding to org-capture is so that one can invoke it anywhere
> anytime. For example, while composing a new mail I might have a great
> idea I want to add to my Notes but I don't care where I invoke
> org-capture as illustrated by the template I use:
>
>  ("n" "Notes" entry (file "Notes.org") "* %?\n  %i" :prepend t)

Okay, I see.  This does not address the real problem but as a workaround
you could have something like

--8<------------------cut here----------------start---------------->8---
emacsclient -e '(org-capture nil "n")'
--8<------------------cut here-----------------end----------------->8---

and bind it to a window manager shortcut.  This will allow you to take a
note even when you're not in emacs ... and of course also when in
emacs/message mode.

> BTW, the reason I have stopped using Gcc (long ago) is that I have gmail
> to do archiving for me. It is accessible anytime anywhere and not tied
> to a specific machine.

This sounds interesting (at least for those that use gmail).  Is the URL
where the archived message will be available predictable, i.e. is it
possible to know it while still composing the message?  If yes, it would
be great to expand `org-gnus-store-link' to either use a Gnus archive
group (Gcc) or a gmail one.

Leo <sdl.web@gmail.com> wrote:

> On 2011-05-05 15:59 +0800, Leo wrote:
>> I believe the following patch is due.
>
> Think about it some more, there is a reason to signal an error when
> calling org-store-link interactively but it should not when invoked by
> org-capture. Otherwise it will get in the way.

I tend to agree but am not completely sure (s.a.).

Ulf

Re: org-capture in message-mode buffer

[Leo]

On 2011-05-05 17:19 +0800, Ulf Stegemann wrote:
[elide 4 lines]
> This sounds interesting (at least for those that use gmail).  Is the URL
> where the archived message will be available predictable, i.e. is it
> possible to know it while still composing the message?  If yes, it would
> be great to expand `org-gnus-store-link' to either use a Gnus archive
> group (Gcc) or a gmail one.

I have started using latest No Gnus and realised the Gcc header is now
enabled per default. But after some trial I turned it off anyway. I use
gmail smtp which does the archiving automatically. I don't know enough
whether that is predictable.

Leo

Re: org-capture in message-mode buffer

[Carsten Dominik]

Hi, 

is there an agreement here on whether the patch appearing in this thread

http://patchwork.newartisans.com/patch/783/

should be applied or not?

- Carsten

On 8.5.2011, at 09:53, Leo wrote:

> On 2011-05-05 17:19 +0800, Ulf Stegemann wrote:
> [elide 4 lines]
>> This sounds interesting (at least for those that use gmail).  Is the URL
>> where the archived message will be available predictable, i.e. is it
>> possible to know it while still composing the message?  If yes, it would
>> be great to expand `org-gnus-store-link' to either use a Gnus archive
>> group (Gcc) or a gmail one.
> 
> I have started using latest No Gnus and realised the Gcc header is now
> enabled per default. But after some trial I turned it off anyway. I use
> gmail smtp which does the archiving automatically. I don't know enough
> whether that is predictable.
> 
> Leo
> 
> 

Re: org-capture in message-mode buffer

[Leo]

On 2011-05-24 11:19 +0800, Carsten Dominik wrote:
> is there an agreement here on whether the patch appearing in this thread
>
> http://patchwork.newartisans.com/patch/783/
>
> should be applied or not?
>
> - Carsten

I don't really know.

The patch merely goes back to the same behaviour before the patch to add
link support for message mode and only when GCC header cannot be found.

But I do use it in my org mode.

Leo

Re: org-capture in message-mode buffer

[Tassilo Horn]

Leo <sdl.web@gmail.com> writes:

Hi!

>> is there an agreement here on whether the patch appearing in this
>> thread
>>
>> http://patchwork.newartisans.com/patch/783/
>>
>> should be applied or not?
>
> I don't really know.

Ditto. :-)

The problem is that creating a link to a message with no Gcc errors
right now.  For interactive use, that's the right thing, I guess.  But
of course preventing `org-capture' from working is bad.

An alternative to the proposed patch is this:

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index a5ece8b..bc5ab20 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -187,7 +187,8 @@ If `org-store-link' was called with a prefix arg the meaning of
 		  group	newsgroups message-id x-no-archive))
       (org-add-link-props :link link :description desc)
       link))
-   ((eq major-mode 'message-mode)
+   ((and (eq major-mode 'message-mode)
+	 (called-interactively-p))
     (setq org-store-link-plist nil)  ; reset
     (save-excursion
       (save-restriction
--8<---------------cut here---------------end--------------->8---

If `org-store-link' is called interactively but no Gcc header is there,
you get an error just like it is right now.  But if it is called
non-interactively through `org-capture', the condition fails and thus no
org-gnus link is created, but a file link to your draft folder.  One may
argue that a file link is not the right thing, either.

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?

Bye,
Tassilo

Re: org-capture in message-mode buffer

[Carsten Dominik]

On May 24, 2011, at 12:41 PM, Tassilo Horn wrote:

> Leo <sdl.web@gmail.com> writes:
> 
> Hi!
> 
>>> is there an agreement here on whether the patch appearing in this
>>> thread
>>> 
>>> http://patchwork.newartisans.com/patch/783/
>>> 
>>> should be applied or not?
>> 
>> I don't really know.
> 
> Ditto. :-)
> 
> The problem is that creating a link to a message with no Gcc errors
> right now.  For interactive use, that's the right thing, I guess.  But
> of course preventing `org-capture' from working is bad.
> 
> An alternative to the proposed patch is this:
> 
> --8<---------------cut here---------------start------------->8---
> diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
> index a5ece8b..bc5ab20 100644
> --- a/lisp/org-gnus.el
> +++ b/lisp/org-gnus.el
> @@ -187,7 +187,8 @@ If `org-store-link' was called with a prefix arg the meaning of
> 		  group	newsgroups message-id x-no-archive))
>       (org-add-link-props :link link :description desc)
>       link))
> -   ((eq major-mode 'message-mode)
> +   ((and (eq major-mode 'message-mode)
> +	 (called-interactively-p))
>     (setq org-store-link-plist nil)  ; reset
>     (save-excursion
>       (save-restriction
> --8<---------------cut here---------------end--------------->8---
> 
> If `org-store-link' is called interactively but no Gcc header is there,
> you get an error just like it is right now.  But if it is called
> non-interactively through `org-capture', the condition fails and thus no
> org-gnus link is created, but a file link to your draft folder.  One may
> argue that a file link is not the right thing, either.
> 
> 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 ?

Regards

- Carsten

Re: org-capture in message-mode buffer

[Tassilo Horn]

Carsten Dominik <carsten.dominik@gmail.com> 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 <tassilo@member.fsf.org>
Date: Tue, 24 May 2011 13:29:53 +0200
Subject: [PATCH 3/3] Ignore errors from link creation.

2011-05-24  Tassilo Horn  <tassilo@member.fsf.org>

	* 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---

Re: org-capture in message-mode buffer

[Carsten Dominik]

On May 24, 2011, at 1:35 PM, Tassilo Horn wrote:

> Carsten Dominik <carsten.dominik@gmail.com> 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 <tassilo@member.fsf.org>
> Date: Tue, 24 May 2011 13:29:53 +0200
> Subject: [PATCH 3/3] Ignore errors from link creation.
> 
> 2011-05-24  Tassilo Horn  <tassilo@member.fsf.org>
> 
> 	* 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