* Org referring to Gnus mail
@ 2012-04-27 1:51 François Pinard
2012-04-27 5:02 ` William Gardella
0 siblings, 1 reply; 4+ messages in thread
From: François Pinard @ 2012-04-27 1:51 UTC (permalink / raw)
To: emacs-orgmode
Hello.
In my Org files, I have many references to Gnus articles which are part
of mailgroups. When batch reading email with Gnus, I'm OK with the
newsreader paradigm, in which an article is almost deleted as soon as it
gets read: it will not show the next time I'll visit the group.
However, when an article is referred through an Org link, I think I
would prefer if the paradigm did not apply. Currently, I see myself
"unreading" such articles all the time, which is a bit tedious, and
error prone as well, as I can easily forget to do it. I wonder if
someone would not imagine some trickery by which, when the reference
comes from Org, the Gnus article does not get automatically read.
If references were always established "manually", I could take the habit
of banging each article on which there is an Org link, at the time I
establish the link. The nicety is that a ticked article does not
"become read" when visited.
However, in the practical case, I have an Emacs command, launching an
external helper program, which finds all articles within all mailgroups
within the few local servers, matching a specific regexp somewhere, and
then outputs a conveniently sorted Org tree holding [[...][...]] links
to them all. As the matches transiently depend on the pattern, it would
prefer avoiding any kind of side effects on the unread articles.
François
P.S. I'm quite surprised by the speed of the search. Grepping through
540 Megs of text distributed in over 10000 files takes a bit less than
half a second, once the memory cache got populated. It's hard for me to
believe, and I'm unsuccessfully looking for a bug. It apparently works!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Org referring to Gnus mail
2012-04-27 1:51 Org referring to Gnus mail François Pinard
@ 2012-04-27 5:02 ` William Gardella
2012-04-27 15:50 ` François Pinard
0 siblings, 1 reply; 4+ messages in thread
From: William Gardella @ 2012-04-27 5:02 UTC (permalink / raw)
To: emacs-orgmode
François Pinard <pinard@iro.umontreal.ca> writes:
> Hello.
>
> In my Org files, I have many references to Gnus articles which are part
> of mailgroups. When batch reading email with Gnus, I'm OK with the
> newsreader paradigm, in which an article is almost deleted as soon as it
> gets read: it will not show the next time I'll visit the group.
>
> However, when an article is referred through an Org link, I think I
> would prefer if the paradigm did not apply. Currently, I see myself
> "unreading" such articles all the time, which is a bit tedious, and
> error prone as well, as I can easily forget to do it. I wonder if
> someone would not imagine some trickery by which, when the reference
> comes from Org, the Gnus article does not get automatically read.
>
> If references were always established "manually", I could take the habit
> of banging each article on which there is an Org link, at the time I
> establish the link. The nicety is that a ticked article does not
> "become read" when visited.
Hi François,
I am sure there is a better answer out there, but there is another
nicety of Gnus you could exploit: marks (including the "read" mark) are
never populated to a Gnus group automatically on reading, but only when
you do an updating command such as q or x. If you close the group with
`gnus-summary-exit-no-update' (the Q key in default binding), these
messages will not be marked as read.
>
> However, in the practical case, I have an Emacs command, launching an
> external helper program, which finds all articles within all mailgroups
> within the few local servers, matching a specific regexp somewhere, and
> then outputs a conveniently sorted Org tree holding [[...][...]] links
> to them all. As the matches transiently depend on the pattern, it would
> prefer avoiding any kind of side effects on the unread articles.
>
> François
>
> P.S. I'm quite surprised by the speed of the search. Grepping through
> 540 Megs of text distributed in over 10000 files takes a bit less than
> half a second, once the memory cache got populated. It's hard for me to
> believe, and I'm unsuccessfully looking for a bug. It apparently works!
So you have a command to automatically populate an Org tree from local
newsgroups? Wow, sounds cool. I've long wondered if Org would make a
good mailreader, and it sounds like you've determined that yes, it could
:)
--
Cheers,
WGG
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Org referring to Gnus mail
2012-04-27 5:02 ` William Gardella
@ 2012-04-27 15:50 ` François Pinard
2012-04-27 22:32 ` Wes Hardaker
0 siblings, 1 reply; 4+ messages in thread
From: François Pinard @ 2012-04-27 15:50 UTC (permalink / raw)
To: emacs-orgmode
William Gardella <gardellawg@gmail.com> writes:
> If you close the group with `gnus-summary-exit-no-update' (the Q key
> in default binding), these messages will not be marked as read.
Indeed, thanks William!
Now, I just have to be careful enough to remember to use "Q" instead of
"q"! When flying around between Emacs buffers and duties, one may get
distracted and forget. Besides, fast key typing too often comes from
the spinal chord rather than the brain! ☺
Maybe I could temporarily unbind "q", or something.
> So you have a command to automatically populate an Org tree from local
> newsgroups? Wow, sounds cool.
Well, only those articles matching some given pattern, not all of them.
I have had this reoccurring need to do wide searches in big set of email
folders, which I used /very/ intensely at times.
The lack of inter-operability in both WorkFlowy and Thunderbird (which I
both liked very much otherwise) was my incentive for switching into Org
and Gnus, but I did not yet re-implement wide searches in Gnus. Having
the need again recently, I tried nnvirtual, which is *way* too slow, and
this is why I quickly kludged a solution which, fun enough, is fast!
> I've long wondered if Org would make a good mailreader, and it sounds
> like you've determined that yes, it could :)
While I clearly see the smiley, let me underline that I do not see Org
as a good mail reader. Gnus is! However, for me, it was much, much
easier to generate an Org tree for matching messages than to write a new
Gnus backend, thanks to the nice integration between Org and Gnus!
François
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Org referring to Gnus mail
2012-04-27 15:50 ` François Pinard
@ 2012-04-27 22:32 ` Wes Hardaker
0 siblings, 0 replies; 4+ messages in thread
From: Wes Hardaker @ 2012-04-27 22:32 UTC (permalink / raw)
To: François Pinard; +Cc: emacs-orgmode
François Pinard <pinard@iro.umontreal.ca> writes:
> Now, I just have to be careful enough to remember to use "Q" instead of
> "q"! When flying around between Emacs buffers and duties, one may get
> distracted and forget. Besides, fast key typing too often comes from
> the spinal chord rather than the brain! ☺
The other option is to teach gnus that read doesn't mean "hide from me".
I have some groups that display read-mail for me, and require I expire
the articles before they're deleted. EG, my inbox. Other groups "read"
means "don't show me again". Like my orgmode group, for example, has
auto-expire set to be true.
--
Wes Hardaker
My Pictures: http://capturedonearth.com/
My Thoughts: http://pontifications.hardakers.net/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-04-27 22:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-27 1:51 Org referring to Gnus mail François Pinard
2012-04-27 5:02 ` William Gardella
2012-04-27 15:50 ` François Pinard
2012-04-27 22:32 ` Wes Hardaker
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).