* org-capture in message-mode buffer
@ 2011-05-04 12:26 Leo
2011-05-04 13:14 ` Ulf Stegemann
0 siblings, 1 reply; 14+ messages in thread
From: Leo @ 2011-05-04 12:26 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: org-capture in message-mode buffer 2011-05-04 12:26 org-capture in message-mode buffer Leo @ 2011-05-04 13:14 ` Ulf Stegemann 2011-05-04 14:36 ` Leo 0 siblings, 1 reply; 14+ messages in thread From: Ulf Stegemann @ 2011-05-04 13:14 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-04 13:14 ` Ulf Stegemann @ 2011-05-04 14:36 ` Leo 2011-05-05 7:02 ` Ulf Stegemann 0 siblings, 1 reply; 14+ messages in thread From: Leo @ 2011-05-04 14:36 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-04 14:36 ` Leo @ 2011-05-05 7:02 ` Ulf Stegemann 2011-05-05 7:59 ` Leo 0 siblings, 1 reply; 14+ messages in thread From: Ulf Stegemann @ 2011-05-05 7:02 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-05 7:02 ` Ulf Stegemann @ 2011-05-05 7:59 ` Leo 2011-05-05 8:09 ` Leo 2011-05-05 9:19 ` Ulf Stegemann 0 siblings, 2 replies; 14+ messages in thread From: Leo @ 2011-05-05 7:59 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-05 7:59 ` Leo @ 2011-05-05 8:09 ` Leo 2011-05-05 9:19 ` Ulf Stegemann 1 sibling, 0 replies; 14+ messages in thread From: Leo @ 2011-05-05 8:09 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-05 7:59 ` Leo 2011-05-05 8:09 ` Leo @ 2011-05-05 9:19 ` Ulf Stegemann 2011-05-08 7:53 ` Leo 1 sibling, 1 reply; 14+ messages in thread From: Ulf Stegemann @ 2011-05-05 9:19 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-05 9:19 ` Ulf Stegemann @ 2011-05-08 7:53 ` Leo 2011-05-24 3:19 ` Carsten Dominik 0 siblings, 1 reply; 14+ messages in thread From: Leo @ 2011-05-08 7:53 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-08 7:53 ` Leo @ 2011-05-24 3:19 ` Carsten Dominik 2011-05-24 3:57 ` Leo 0 siblings, 1 reply; 14+ messages in thread From: Carsten Dominik @ 2011-05-24 3:19 UTC (permalink / raw) To: Leo; +Cc: emacs-orgmode 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 > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-24 3:19 ` Carsten Dominik @ 2011-05-24 3:57 ` Leo 2011-05-24 10:41 ` Tassilo Horn 0 siblings, 1 reply; 14+ messages in thread From: Leo @ 2011-05-24 3:57 UTC (permalink / raw) To: Carsten Dominik; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-24 3:57 ` Leo @ 2011-05-24 10:41 ` Tassilo Horn 2011-05-24 10:56 ` Carsten Dominik 0 siblings, 1 reply; 14+ messages in thread From: Tassilo Horn @ 2011-05-24 10:41 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-24 10:41 ` Tassilo Horn @ 2011-05-24 10:56 ` Carsten Dominik 2011-05-24 11:35 ` Tassilo Horn 0 siblings, 1 reply; 14+ messages in thread From: Carsten Dominik @ 2011-05-24 10:56 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-24 10:56 ` Carsten Dominik @ 2011-05-24 11:35 ` Tassilo Horn 2011-05-24 11:38 ` Carsten Dominik 0 siblings, 1 reply; 14+ messages in thread From: Tassilo Horn @ 2011-05-24 11:35 UTC (permalink / raw) To: Carsten Dominik; +Cc: emacs-orgmode 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--- ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: org-capture in message-mode buffer 2011-05-24 11:35 ` Tassilo Horn @ 2011-05-24 11:38 ` Carsten Dominik 0 siblings, 0 replies; 14+ messages in thread From: Carsten Dominik @ 2011-05-24 11:38 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-05-24 11:38 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-04 12:26 org-capture in message-mode buffer Leo 2011-05-04 13:14 ` Ulf Stegemann 2011-05-04 14:36 ` Leo 2011-05-05 7:02 ` Ulf Stegemann 2011-05-05 7:59 ` Leo 2011-05-05 8:09 ` Leo 2011-05-05 9:19 ` Ulf Stegemann 2011-05-08 7:53 ` Leo 2011-05-24 3:19 ` Carsten Dominik 2011-05-24 3:57 ` Leo 2011-05-24 10:41 ` Tassilo Horn 2011-05-24 10:56 ` Carsten Dominik 2011-05-24 11:35 ` Tassilo Horn 2011-05-24 11:38 ` Carsten Dominik
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).