From: Ulf Stegemann <ulf-news@zeitform.de>
To: emacs-orgmode@gnu.org
Subject: Re: org-capture in message-mode buffer
Date: Thu, 05 May 2011 11:19:05 +0200 [thread overview]
Message-ID: <zf.upn8vulmrna.fsf@zeitform.de> (raw)
In-Reply-To: m1aaf1tw6k.fsf@gmail.com
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
next prev parent reply other threads:[~2011-05-05 9:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
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=zf.upn8vulmrna.fsf@zeitform.de \
--to=ulf-news@zeitform.de \
--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).