* Behavior of Gnus when called from an hyperlink
@ 2010-06-28 9:38 Sébastien Vauban
2010-06-28 10:19 ` Tassilo Horn
0 siblings, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-06-28 9:38 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi all,
Would someone have a chunk of config to share for the Gnus/Org integration?
I'm using Gnus for years, with a very high level of satisfaction, and Org for
a bit less, with even more satisfaction -- yes, more than "very high" is
possible ;-)
What I didn't use yet was the integration of both: linking onto a Gnus
hyperlink and getting to that email. Though, when doing it, now, I experience
the following problem:
- a new frame is opened
Besides that I more or less hate frames, it becomes annoying when used in my
StumpWM config: I now have *two* Emacs full screen, and I loose my "single
window of control" view.
- a new buffer is opened (group where the mail belongs to), but it takes ages
(in minutes) for the mail to be found and opened -- when it is.
I'm not sure what I've to fiddle with. Maybe using gnus-registry for the
second point?
Anyway, if someone would be kind enough to share his current working config, I
would try digging and comparing the versions to find the explicit root of the
problems.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-06-28 9:38 Behavior of Gnus when called from an hyperlink Sébastien Vauban
@ 2010-06-28 10:19 ` Tassilo Horn
2010-06-28 11:36 ` Leo
2010-06-28 12:05 ` Sébastien Vauban
0 siblings, 2 replies; 77+ messages in thread
From: Tassilo Horn @ 2010-06-28 10:19 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
Hi Sébastien,
> - a new frame is opened
>
> Besides that I more or less hate frames, it becomes annoying when
> used in my StumpWM config: I now have *two* Emacs full screen, and I
> loose my "single window of control" view.
That's because the default value of org-link-frame-setup prefers a new
frame. Dunno if that's a good default. It's more Macish than
Emacsish...
So I use that config:
(setq org-link-frame-setup '((vm . vm-visit-folder)
(gnus . org-gnus-no-new-news)
(file . find-file-other-window)))
> - a new buffer is opened (group where the mail belongs to), but it
> takes ages (in minutes) for the mail to be found and opened -- when it
> is.
Hm, what backend do you use?
I've just tried it with a nntp group and linked a very old message.
When I follow that link, I'm at the right article in less than a second.
Do you deactivate some of Gnus caches or NOV files? That could slow
down mail access quite a bit.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-06-28 10:19 ` Tassilo Horn
@ 2010-06-28 11:36 ` Leo
2010-06-28 11:49 ` Carsten Dominik
2010-06-28 12:05 ` Sébastien Vauban
1 sibling, 1 reply; 77+ messages in thread
From: Leo @ 2010-06-28 11:36 UTC (permalink / raw)
To: emacs-orgmode
On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
> (setq org-link-frame-setup '((vm . vm-visit-folder)
> (gnus . org-gnus-no-new-news)
> (file . find-file-other-window)))
Nice.
I have also found creating new frame a bit annoying because I tend to
have fullscreened emacs and really don't like a frame to pop into my
face.
Leo
--
Any Emacs contains an ad hoc, informally-specified, bug-ridden, slow
implementation of half of Common Lisp.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Behavior of Gnus when called from an hyperlink
2010-06-28 11:36 ` Leo
@ 2010-06-28 11:49 ` Carsten Dominik
2010-06-28 12:47 ` Bernt Hansen
` (4 more replies)
0 siblings, 5 replies; 77+ messages in thread
From: Carsten Dominik @ 2010-06-28 11:49 UTC (permalink / raw)
To: Leo; +Cc: emacs-orgmode
On Jun 28, 2010, at 1:36 PM, Leo wrote:
> On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
>> (setq org-link-frame-setup '((vm . vm-visit-folder)
>> (gnus . org-gnus-no-new-news)
>> (file . find-file-other-window)))
>
> Nice.
>
> I have also found creating new frame a bit annoying because I tend to
> have fullscreened emacs and really don't like a frame to pop into my
> face.
I don't remember why I made creating a new frame the default.
Probably back then I used to have a special frame for GNUS open.
Anyway, if there is enough momentum here, we can change the default.
- Carsten
>
> Leo
>
>
> --
> Any Emacs contains an ad hoc, informally-specified, bug-ridden, slow
> implementation of half of Common Lisp.
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
- Carsten
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-06-28 11:49 ` Carsten Dominik
@ 2010-06-28 12:47 ` Bernt Hansen
2010-06-28 13:57 ` Greg Troxel
` (3 subsequent siblings)
4 siblings, 0 replies; 77+ messages in thread
From: Bernt Hansen @ 2010-06-28 12:47 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode, Leo
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Jun 28, 2010, at 1:36 PM, Leo wrote:
>
>> On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
>>> (setq org-link-frame-setup '((vm . vm-visit-folder)
>>> (gnus . org-gnus-no-new-news)
>>> (file . find-file-other-window)))
>>
>> Nice.
>>
>> I have also found creating new frame a bit annoying because I tend to
>> have fullscreened emacs and really don't like a frame to pop into my
>> face.
>
> I don't remember why I made creating a new frame the default.
> Probably back then I used to have a special frame for GNUS open.
> Anyway, if there is enough momentum here, we can change the default.
I also use this setup. I run emacs in fullscreen and prefer opening
things in the same window.
-Bernt
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Re: Behavior of Gnus when called from an hyperlink
2010-06-28 11:49 ` Carsten Dominik
2010-06-28 12:47 ` Bernt Hansen
@ 2010-06-28 13:57 ` Greg Troxel
2010-06-28 19:44 ` [PATCH] Add customization for WL in `org-link-frame-setup' David Maus
` (2 subsequent siblings)
4 siblings, 0 replies; 77+ messages in thread
From: Greg Troxel @ 2010-06-28 13:57 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode, Leo
[-- Attachment #1.1: Type: text/plain, Size: 1191 bytes --]
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Jun 28, 2010, at 1:36 PM, Leo wrote:
>
>> On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
>>> (setq org-link-frame-setup '((vm . vm-visit-folder)
>>> (gnus . org-gnus-no-new-news)
>>> (file . find-file-other-window)))
>>
>> I have also found creating new frame a bit annoying because I tend to
>> have fullscreened emacs and really don't like a frame to pop into my
>> face.
>
> I don't remember why I made creating a new frame the default.
> Probably back then I used to have a special frame for GNUS open.
> Anyway, if there is enough momentum here, we can change the default.
I also don't want a new frame.
Part of the problem with the new frame is that if I exit the article I
am back in Summary and it's tempting to quit that - because it was
perhaps just created for me and then I'm out of gnus.
It's almost like the article needs a buffer-local hook to exit
differently. Maybe this is something gnus needs to support more, a
"show this article, but don't mess with the summary buffer or any other
gnus state", or maybe it does already and I just don't understand.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 194 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* [PATCH] Add customization for WL in `org-link-frame-setup'
2010-06-28 11:49 ` Carsten Dominik
2010-06-28 12:47 ` Bernt Hansen
2010-06-28 13:57 ` Greg Troxel
@ 2010-06-28 19:44 ` David Maus
2010-06-29 4:42 ` Carsten Dominik
2010-06-28 19:44 ` [PATCH] Add customization option to open WL links in other frame David Maus
2010-06-30 10:12 ` Behavior of Gnus when called from an hyperlink Noorul Islam K M
4 siblings, 1 reply; 77+ messages in thread
From: David Maus @ 2010-06-28 19:44 UTC (permalink / raw)
To: emacs-orgmode
Didn't even know about this customization variable and used a hack of
org-wl to actually open links in an other frame.
So here is a patch that adds a customization option for WL links to
`org-link-frame-setup'.
Best,
-- David
David Maus (1):
Add customization option to open WL links in other frame.
lisp/org.el | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
^ permalink raw reply [flat|nested] 77+ messages in thread
* [PATCH] Add customization option to open WL links in other frame.
2010-06-28 11:49 ` Carsten Dominik
` (2 preceding siblings ...)
2010-06-28 19:44 ` [PATCH] Add customization for WL in `org-link-frame-setup' David Maus
@ 2010-06-28 19:44 ` David Maus
2010-06-30 10:12 ` Behavior of Gnus when called from an hyperlink Noorul Islam K M
4 siblings, 0 replies; 77+ messages in thread
From: David Maus @ 2010-06-28 19:44 UTC (permalink / raw)
To: emacs-orgmode
* org.el (org-link-frame-setup): Add customization option for
Wanderlust.
---
lisp/org.el | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 1029fa1..a079179 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1387,7 +1387,8 @@ Changing this requires a restart of Emacs to work correctly."
(defcustom org-link-frame-setup
'((vm . vm-visit-folder-other-frame)
(gnus . gnus-other-frame)
- (file . find-file-other-window))
+ (file . find-file-other-window)
+ (wl . wl-other-frame))
"Setup the frame configuration for following links.
When following a link with Emacs, it may often be useful to display
this link in another window or frame. This variable can be used to
@@ -1403,6 +1404,9 @@ For FILE, use any of
`find-file'
`find-file-other-window'
`find-file-other-frame'
+For Wanderlust use any of
+ `wl'
+ `wl-other-frame'
For the calendar, use the variable `calendar-setup'.
For BBDB, it is currently only possible to display the matches in
another window."
@@ -1422,7 +1426,11 @@ another window."
(choice
(const find-file)
(const find-file-other-window)
- (const find-file-other-frame)))))
+ (const find-file-other-frame)))
+ (cons (const wl)
+ (choice
+ (const wl)
+ (const wl-other-frame)))))
(defcustom org-display-internal-link-with-indirect-buffer nil
"Non-nil means use indirect buffer to display infile links.
--
1.7.1
^ permalink raw reply related [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-06-28 11:49 ` Carsten Dominik
` (3 preceding siblings ...)
2010-06-28 19:44 ` [PATCH] Add customization option to open WL links in other frame David Maus
@ 2010-06-30 10:12 ` Noorul Islam K M
2010-07-02 4:44 ` Carsten Dominik
4 siblings, 1 reply; 77+ messages in thread
From: Noorul Islam K M @ 2010-06-30 10:12 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode, Leo
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Jun 28, 2010, at 1:36 PM, Leo wrote:
>
>> On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
>>> (setq org-link-frame-setup '((vm . vm-visit-folder)
>>> (gnus . org-gnus-no-new-news)
>>> (file . find-file-other-window)))
>>
>> Nice.
>>
>> I have also found creating new frame a bit annoying because I tend to
>> have fullscreened emacs and really don't like a frame to pop into my
>> face.
>
> I don't remember why I made creating a new frame the default.
> Probably back then I used to have a special frame for GNUS open.
> Anyway, if there is enough momentum here, we can change the default.
>
I run gnus and face similar problem. I ignored it so far. I prefer opening
mail in the same window.
Thanks and Regards
Noorul
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-06-30 10:12 ` Behavior of Gnus when called from an hyperlink Noorul Islam K M
@ 2010-07-02 4:44 ` Carsten Dominik
2010-07-02 8:21 ` Leo
` (2 more replies)
0 siblings, 3 replies; 77+ messages in thread
From: Carsten Dominik @ 2010-07-02 4:44 UTC (permalink / raw)
To: Noorul Islam K M; +Cc: emacs-orgmode, Leo
Hi,
do we have an agreement that the default frame setup for gnus should
be org-gnus-no-new-news?
- Carsten
On Jun 30, 2010, at 12:12 PM, Noorul Islam K M wrote:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On Jun 28, 2010, at 1:36 PM, Leo wrote:
>>
>>> On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
>>>> (setq org-link-frame-setup '((vm . vm-visit-folder)
>>>> (gnus . org-gnus-no-new-news)
>>>> (file . find-file-other-window)))
>>>
>>> Nice.
>>>
>>> I have also found creating new frame a bit annoying because I tend
>>> to
>>> have fullscreened emacs and really don't like a frame to pop into my
>>> face.
>>
>> I don't remember why I made creating a new frame the default.
>> Probably back then I used to have a special frame for GNUS open.
>> Anyway, if there is enough momentum here, we can change the default.
>>
>
> I run gnus and face similar problem. I ignored it so far. I prefer
> opening
> mail in the same window.
>
> Thanks and Regards
> Noorul
- Carsten
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-06-28 10:19 ` Tassilo Horn
2010-06-28 11:36 ` Leo
@ 2010-06-28 12:05 ` Sébastien Vauban
2010-06-28 12:51 ` Sébastien Vauban
1 sibling, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-06-28 12:05 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>
>> - a new frame is opened
>>
>> Besides that I more or less hate frames, it becomes annoying when used in
>> my StumpWM config: I now have *two* Emacs full screen, and I loose my
>> "single window of control" view.
>
> That's because the default value of org-link-frame-setup prefers a new
> frame. Dunno if that's a good default. It's more Macish than Emacsish...
>
> So I use that config:
>
> (setq org-link-frame-setup '((vm . vm-visit-folder)
> (gnus . org-gnus-no-new-news)
> (file . find-file-other-window)))
Tested. Perfect! Thanks a lot...
>> - a new buffer is opened (group where the mail belongs to), but it takes
>> ages (in minutes) for the mail to be found and opened -- when it is.
>
> Hm, what backend do you use?
nnimap.
For nntp, I let Org link to the Gmane groups anyway (so, calling Firefox when
clicking on such hyperlinks).
> I've just tried it with a nntp group and linked a very old message. When I
> follow that link, I'm at the right article in less than a second.
I don't have the *impression* that it has to do with the fact that the message
is old or new.
Tested links to mails belonging to two different groups:
--8<---------------cut here---------------start------------->8---
nnimap+me:INBOX.abc 0 Unread/ 1963 Items
nnimap+me:INBOX.work 25 Unread/ 28611 Items
--8<---------------cut here---------------end--------------->8---
Both mails are from today.
Clicking on the first hyperlink (mail from ABC), I get it in front of me in a
couple of seconds (did not really measured, but acceptable anyway).
Though, for the mail belonging to my `work' group, it took 5 min 21 seconds...
(IMAP Courier server on Debian, local network, 100 Mbps, so the bandwidth
should not be an issue).
What do you think of this?
> Do you deactivate some of Gnus caches
--8<---------------cut here---------------start------------->8---
;; use the cache
(setq gnus-use-cache nil)
;; local cache
(setq gnus-cache-directory (concat my-gnus-root-dir "Mail/cache/"))
;; entering of articles from the cache
(setq gnus-cache-enter-articles '(ticked dormant unread read))
;; simple setup for your convenience, if you are using `nnimap' from
;; home, over a dialup connection
;; removing of articles from the cache
(setq gnus-cache-remove-articles nil)
;; cache your nnimap groups
(setq gnus-cacheable-groups "^nnimap")
;; avoid caching your nnml and nnfolder groups
(setq gnus-uncacheable-groups "^nnml\\|^nnfolder")
;; cache of old Message-IDs for every message Gnus sees
(setq nnmail-message-id-cache-file
(concat my-gnus-root-dir "Mail/.nnmail-cache"))
;; whether the registry should be installed
(setq gnus-registry-install t)
;; whether the registry should use long group names
(setq gnus-registry-use-long-group-names t)
;; unlimited number of entries in the registry
(setq gnus-registry-max-entries nil)
--8<---------------cut here---------------end--------------->8---
> or NOV files?
gnus-nov-is-evil's value is nil.
> That could slow down mail access quite a bit.
Maybe turning back up `gnus-use-cache', then?
Thanks for your help.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-06-28 12:05 ` Sébastien Vauban
@ 2010-06-28 12:51 ` Sébastien Vauban
2010-06-28 14:39 ` Nick Dokos
0 siblings, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-06-28 12:51 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo,
Sébastien Vauban wrote:
> Tassilo Horn wrote:
>> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-XMD5yJDbdMRG2NFembrH+g@public.gmane.orgorg> writes:
>>>
>>> - a new buffer is opened (group where the mail belongs to), but it takes
>>> ages (in minutes) for the mail to be found and opened -- when it is.
>>
>> I've just tried it with a nntp group and linked a very old message. When I
>> follow that link, I'm at the right article in less than a second.
>
> Tested links to mails belonging to two different groups:
>
> nnimap+me:INBOX.abc 0 Unread/ 1963 Items
> nnimap+me:INBOX.work 25 Unread/ 28611 Items
>
> [...] for the mail belonging to my `work' group, it took 5 min 21 seconds...
>
> What do you think of this?
>
>
>> Do you deactivate some of Gnus caches
>
> ;; use the cache
> (setq gnus-use-cache nil)
I've updated it to `t'.
> ;; local cache
> (setq gnus-cache-directory (concat my-gnus-root-dir "Mail/cache/"))
>
> ;; entering of articles from the cache
> (setq gnus-cache-enter-articles '(ticked dormant unread read))
> ;; simple setup for your convenience, if you are using `nnimap' from
> ;; home, over a dialup connection
>
> ;; removing of articles from the cache
> (setq gnus-cache-remove-articles nil)
>
> ;; cache your nnimap groups
> (setq gnus-cacheable-groups "^nnimap")
>
> ;; avoid caching your nnml and nnfolder groups
> (setq gnus-uncacheable-groups "^nnml\\|^nnfolder")
>
> ;; cache of old Message-IDs for every message Gnus sees
> (setq nnmail-message-id-cache-file
> (concat my-gnus-root-dir "Mail/.nnmail-cache"))
>
> ;; whether the registry should be installed
> (setq gnus-registry-install t)
>
> ;; whether the registry should use long group names
> (setq gnus-registry-use-long-group-names t)
>
> ;; unlimited number of entries in the registry
> (setq gnus-registry-max-entries nil)
Rest stayed as it was.
I've read the couple of mails I was linking to. I've restarted Emacs (and
Gnus) a couple of times.
No change.
It still takes around 5 mins to find the mail in my `work' group. Even when
clicking a second time in the same Emacs/Gnus session.
I've checked the cache; in /home/sva/Mail/cache/nnimap+me:INBOX.work, I have a
copy of the linked email:
-rw-r--r-- 1 sva sva 1631 2010-06-28 14:09 28606
I really don't understand the problem.
And, if I interrupt that 5-min process, Gnus becomes completely unusable. C-g,
then g is completely stuck. Going to the servers list (via ^) does not work
either. I'm forced to restart Emacs and Gnus.
And still 5 minutes to find the linked email, in the next session.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Behavior of Gnus when called from an hyperlink
2010-06-28 12:51 ` Sébastien Vauban
@ 2010-06-28 14:39 ` Nick Dokos
2010-06-28 14:51 ` Sébastien Vauban
0 siblings, 1 reply; 77+ messages in thread
From: Nick Dokos @ 2010-06-28 14:39 UTC (permalink / raw)
To: =?utf-8?Q?S=C3=A9bastien_Vauban?=; +Cc: nicholas.dokos, emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
> > (setq gnus-use-cache nil)
>
> I've updated it to `t'.
>
> ...
>
> Rest stayed as it was.
>
> I've read the couple of mails I was linking to. I've restarted Emacs (and
> Gnus) a couple of times.
>
> No change.
>
> It still takes around 5 mins to find the mail in my `work' group. Even when
> clicking a second time in the same Emacs/Gnus session.
>
> I've checked the cache; in /home/sva/Mail/cache/nnimap+me:INBOX.work, I have a
> copy of the linked email:
>
> -rw-r--r-- 1 sva sva 1631 2010-06-28 14:09 28606
>
> I really don't understand the problem.
>
Profile the gnus code as it processes the two requests? The differences should
be telling.
Cheers,
Nick
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-06-28 14:39 ` Nick Dokos
@ 2010-06-28 14:51 ` Sébastien Vauban
2010-06-28 15:19 ` Nick Dokos
2010-06-28 18:32 ` Tassilo Horn
0 siblings, 2 replies; 77+ messages in thread
From: Sébastien Vauban @ 2010-06-28 14:51 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Nick,
Nick Dokos wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> wrote:
>
>> > (setq gnus-use-cache nil)
>>
>> I've updated it to `t'.
>>
>> ...
>>
>> Rest stayed as it was.
>>
>> I've read the couple of mails I was linking to. I've restarted Emacs (and
>> Gnus) a couple of times.
>>
>> No change.
>>
>> It still takes around 5 mins to find the mail in my `work' group. Even when
>> clicking a second time in the same Emacs/Gnus session.
>>
>> I've checked the cache; in /home/sva/Mail/cache/nnimap+me:INBOX.work, I have a
>> copy of the linked email:
>>
>> -rw-r--r-- 1 sva sva 1631 2010-06-28 14:09 28606
>>
>> I really don't understand the problem.
>
> Profile the gnus code as it processes the two requests? The differences should
> be telling.
Could you just give me a hint (function name or so) or a place to look for
some info on how to do that?
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Behavior of Gnus when called from an hyperlink
2010-06-28 14:51 ` Sébastien Vauban
@ 2010-06-28 15:19 ` Nick Dokos
2010-06-28 18:32 ` Tassilo Horn
1 sibling, 0 replies; 77+ messages in thread
From: Nick Dokos @ 2010-06-28 15:19 UTC (permalink / raw)
To: =?utf-8?Q?S=C3=A9bastien_Vauban?=; +Cc: nicholas.dokos, emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
> >> I really don't understand the problem.
> >
> > Profile the gnus code as it processes the two requests? The differences should
> > be telling.
>
> Could you just give me a hint (function name or so) or a place to look for
> some info on how to do that?
>
I 've used the blunter instrument with org in the past:
M-x elp-instrument-package <RET> gnus <RET>
There is a sharper scalpel too:
M-x elp=instrument-function <RET> some-func <RET>
Cheers,
Nick
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-06-28 14:51 ` Sébastien Vauban
2010-06-28 15:19 ` Nick Dokos
@ 2010-06-28 18:32 ` Tassilo Horn
2010-07-15 21:27 ` Sébastien Vauban
1 sibling, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-06-28 18:32 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
Hi Sébastien,
that is takes so long for one group but the other group on the same
server is fast is really strange, and currently I don't understand what
might cause that... :-(
>> Profile the gnus code as it processes the two requests? The
>> differences should be telling.
>
> Could you just give me a hint (function name or so) or a place to look
> for some info on how to do that?
I'd edebug the function `org-gnus-follow-link'. It'll be cool if you
could tell me what is the long running function in there.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-06-28 18:32 ` Tassilo Horn
@ 2010-07-15 21:27 ` Sébastien Vauban
2010-07-16 7:50 ` Tassilo Horn
0 siblings, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-15 21:27 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>
> that is takes so long for one group but the other group on the same server
> is fast is really strange, and currently I don't understand what might cause
> that... :-(
>
>>> Profile the gnus code as it processes the two requests? The differences
>>> should be telling.
>>
>> Could you just give me a hint (function name or so) or a place to look for
>> some info on how to do that?
>
> I'd edebug the function `org-gnus-follow-link'. It'll be cool if you could
> tell me what is the long running function in there.
I've followed Nick's procedure, hoping to get even more details:
--8<---------------cut here---------------start------------->8---
Function Name Call Count Elapsed Time Average Time
org-return 1 336.683827 336.683827
org-open-at-point 1 336.683692 336.683692
org-gnus-open 1 336.681615 336.681615
org-gnus-follow-link 1 336.681557 336.681557
gnus-summary-goto-article 1 315.14423 315.14423
gnus-summary-refer-article 1 315.144193 315.144193
gnus-summary-insert-subject 1 313.003412 313.003412
gnus-read-header 1 312.994378 312.994378
gnus-request-head 1 312.993525 312.993525
gnus-activate-group 1 13.587475 13.587475
gnus-group-read-group 1 7.949638 7.949638
gnus-summary-read-group 1 7.9496 7.9496
gnus-summary-read-group-1 1 7.949586 7.949586
gnus-select-newsgroup 1 7.851293 7.851293
gnus-request-group 1 6.671263 6.671263
gnus-server-opened 4 3.3126420000 0.8281605000
gnus-summary-select-article 1 2.104991 2.104991
gnus-summary-display-article 1 2.104918 2.104918
gnus-article-prepare 1 2.097906 2.097906
gnus-request-article-this-buffer 2 1.9062480000 0.9531240000
gnus-check-group-server 1 1.795364 1.795364
gnus-request-scan 1 1.397761 1.397761
gnus-check-server 2 1.123801 0.5619005
org-metaup 4 0.384125 0.09603125
org-move-subtree-up 4 0.381949 0.09548725
org-move-subtree-down 4 0.38187 0.0954675
org-save-markers-in-region 3 0.3645089999 0.1215029999
org-agenda-save-markers-for-cut-and-paste 3 0.364005 0.1213350000
org-check-and-save-marker 714 0.3588209999 0.0005025504
org-shifttab 8 0.1567440000 0.0195930000
org-global-cycle 8 0.15602 0.0195025
org-cycle 8 0.1558119999 0.0194764999
org-cycle-internal-global 8 0.148777 0.018597125
gnus-run-hooks 22 0.1334939999 0.0060679090
gnus-summary-mark-read-and-unread-as-read 1 0.1245699999 0.1245699999
gnus-summary-mark-article 1 0.1244720000 0.1244720000
gnus-cache-possibly-enter-article 1 0.1239040000 0.1239040000
gnus-request-article 1 0.096945 0.096945
gnus-write-buffer 1 0.089033 0.089033
gnus-mode-line-buffer-identification 5 0.08699 0.017398
org-kill-line 8 0.0711519999 0.0088939999
org-content 3 0.066565 0.0221883333
gnus-set-mode-line 3 0.060034 0.0200113333
gnus-fetch-headers 1 0.048193 0.048193
gnus-retrieve-headers 1 0.040212 0.040212
gnus-cache-retrieve-headers 1 0.040185 0.040185
gnus-articles-to-read 1 0.038049 0.038049
org-overview 3 0.0368600000 0.0122866666
gnus-cache-change-buffer 1 0.031713 0.031713
gnus-group-update-group 1 0.030577 0.030577
gnus-group-set-mode-line 2 0.0284239999 0.0142119999
gnus-article-prepare-display 1 0.027133 0.027133
gnus-compress-sequence 14 0.026634 0.0019024285
org-cycle-hide-drawers 11 0.02403 0.0021845454
gnus-message 24 0.0217390000 0.0009057916
gnus-cache-articles-in-group 1 0.020799 0.020799
gnus-display-mime 1 0.019465 0.019465
gnus-possibly-score-headers 1 0.018362 0.018362
gnus-treat-article 2 0.016278 0.008139
gnus-uncompress-range 1 0.015935 0.015935
org-unfontify-region 124 0.0153450000 0.00012375
gnus-killed-articles 1 0.014732 0.014732
org-flag-drawer 58 0.014567 0.0002511551
gnus-dribble-enter 1 0.014054 0.014054
org-outline-level 819 0.0131580000 1.606...e-05
gnus-summary-prepare-threads 2 0.012881 0.0064405
gnus-all-score-files 1 0.012223 0.012223
org-cycle-show-empty-lines 11 0.0102020000 0.0009274545
org-activate-plain-links 151 0.0101089999 6.694...e-05
org-end-of-subtree 22 0.009996 0.0004543636
gnus-score-find-bnews 1 0.009768 0.009768
gnus-score-score-files 1 0.008979 0.008979
gnus-rebuild-thread 1 0.008969 0.008969
gnus-group-find-parameter 10 0.008426 0.0008426
gnus-group-topic-parameters 10 0.0073270000 0.0007327000
gnus-configure-frame 5 0.0072150000 0.0014430000
org-hide-wide-columns 124 0.0070229999 5.663...e-05
gnus-summary-recenter 1 0.006769 0.006769
gnus-summary-setup-buffer 1 0.006684 0.006684
gnus-date-iso8601 20 0.006588 0.0003294
org-activate-footnote-links 124 0.0062759999 5.061...e-05
org-do-emphasis-faces 127 0.0061319999 4.828...e-05
gnus-score-headers 1 0.006092 0.006092
org-clean-visibility-after-subtree-move 3 0.005945 0.0019816666
org-activate-bracket-links 150 0.0056940000 3.796...e-05
gnus-summary-prepare 1 0.005558 0.005558
gnus-get-newsgroup-headers-xover 1 0.005483 0.005483
gnus-group-fast-parameter 8 0.0051429999 0.0006428749
org-imenu-get-tree 1 0.005014 0.005014
gnus-configure-windows 3 0.0049840000 0.0016613333
org-activate-dates 191 0.0049809999 2.607...e-05
gnus-get-buffer-create 8 0.004478 0.00055975
org-fontify-meta-lines-and-blocks 131 0.0041610000 3.176...e-05
org-activate-tags 130 0.0040840000 3.141...e-05
gnus-summary-mode 1 0.004039 0.004039
gnus-range-add 2 0.0034140000 0.0017070000
gnus-topic-hierarchical-parameters 10 0.003265 0.0003265
org-metaright 1 0.002653 0.002653
gnus-topic-parent-topic 55 0.0025829999 4.696...e-05
org-get-last-sibling 9 0.0025390000 0.0002821111
gnus-current-topics 10 0.002537 0.0002537000
gnus-group-goto-group 10 0.0024769999 0.0002476999
org-do-demote 1 0.00246 0.00246
org-demote 1 0.002362 0.002362
gnus-group-decoded-name 9 0.002235 0.0002483333
org-activate-angle-links 124 0.002206 1.779...e-05
org-babel-get-src-block-info 5 0.002192 0.0004384
gnus-article-add-buttons 1 0.002045 0.002045
gnus-remassoc 58 0.0020130000 3.470...e-05
org-babel-load-in-session-maybe 4 0.001973 0.00049325
gnus-group-name-decode 11 0.0019370000 0.0001760909
gnus-build-sparse-threads 1 0.00192 0.00192
org-remove-font-lock-display-properties 124 0.0019080000 1.538...e-05
gnus-summary-set-local-parameters 1 0.001905 0.001905
gnus-score-string 2 0.001859 0.0009295
org-remove-flyspell-overlays-in 129 0.0018009999 1.396...e-05
org-babel-where-is-src-block-head 5 0.0017829999 0.0003566
gnus-cache-file-name 5 0.001778 0.0003556
org-fixup-indentation 1 0.001696 0.001696
gnus-article-emphasize 1 0.001641 0.001641
org-activate-code 124 0.0016290000 1.313...e-05
gnus-summary-setup-default-charset 1 0.001523 0.001523
gnus-article-maybe-hide-headers 1 0.001438 0.001438
gnus-update-format-specifications 2 0.001392 0.000696
gnus-article-hide-headers 1 0.001387 0.001387
org-font-lock-add-tag-faces 124 0.0012550000 1.012...e-05
org-cycle-hide-archived-subtrees 8 0.001216 0.000152
gnus-sort-threads 1 0.001213 0.001213
gnus-group-auto-expirable-p 1 0.001186 0.001186
org-get-todo-face 51 0.0011519999 2.258...e-05
org-get-next-sibling 8 0.001089 0.000136125
org-indent-to-column 7 0.001076 0.0001537142
org-font-lock-add-priority-faces 124 0.0010520000 8.483...e-06
org-get-level-face 246 0.0010060000 4.089...e-06
gnus-current-topic 10 0.000933 9.33e-05
org-hide-archived-subtrees 5 0.000917 0.0001833999
gnus-parameter-charset 1 0.000914 0.000914
gnus-update-summary-mark-positions 1 0.000899 0.000899
gnus-topic-update-topic-line 2 0.00088 0.00044
gnus-adjust-marked-articles 1 0.000795 0.000795
gnus-summary-insert-line 2 0.0007830000 0.0003915000
gnus-set-global-variables 7 0.000782 0.0001117142
gnus-update-alist-soft 12 0.0007640000 6.366...e-05
org-at-table-p 22 0.000752 3.418...e-05
gnus-make-sort-function 1 0.000741 0.000741
gnus-run-mode-hooks 1 0.000735 0.000735
gnus-group-insert-group-line-info 1 0.000718 0.000718
gnus-topic-update-topics-containing-group 1 0.000695 0.000695
org-hide-block-toggle-maybe 8 0.000686 8.575e-05
gnus-group-insert-group-line 1 0.00067 0.00067
gnus-update-read-articles 1 0.000665 0.000665
org-context 1 0.000658 0.000658
gnus-cache-decoded-group-name 5 0.0006339999 0.0001268
gnus-article-highlight-citation 1 0.000597 0.000597
gnus-article-treat-unfold-headers 1 0.000589 0.000589
org-do-latex-and-special-faces 124 0.0005839999 4.709...e-06
gnus-parameter-ignored-charsets 1 0.000576 0.000576
gnus-cite-parse-maybe 1 0.000549 0.000549
gnus-all-windows-visible-p 3 0.000544 0.0001813333
gnus-byte-compile 1 0.00054 0.00054
gnus-cite-parse-wrapper 1 0.000526 0.000526
org-first-sibling-p 3 0.00051 0.00017
gnus-get-buffer-window 8 0.000505 6.3125e-05
gnus-buffer-live-p 112 0.0004899999 4.374...e-06
org-back-over-empty-lines 11 0.0004860000 4.418...e-05
gnus-group-set-parameter 5 0.000481 9.62e-05
org-back-to-heading 28 0.000466 1.664...e-05
gnus-article-add-buttons-to-head 1 0.000464 0.000464
gnus-summary-position-point 12 0.000463 3.858...e-05
gnus-summary-auto-select-subject 1 0.000459 0.000459
gnus-article-setup-buffer 1 0.000454 0.000454
gnus-summary-first-unread-subject 1 0.000452 0.000452
gnus-remove-from-range 4 0.000451 0.00011275
gnus-mode-string-quote 5 0.0004509999 9.02e-05
org-in-regexp 2 0.000446 0.000223
gnus-summary-first-subject 1 0.000428 0.000428
org-font-lock-hook 124 0.0004149999 3.346...e-06
gnus-summary-goto-subject 4 0.0004030000 0.0001007500
gnus-article-setup-highlight-words 1 0.0004 0.0004
org-raise-scripts 124 0.0003959999 3.193...e-06
gnus-continuum-version 4 0.00039 9.75e-05
gnus-copy-sequence 25 0.0003899999 1.559...e-05
org-footnote-at-reference-p 1 0.000386 0.000386
gnus-apply-kill-file 1 0.000384 0.000384
org-activate-target-links 124 0.0003779999 3.048...e-06
gnus-topic-parameters 20 0.0003759999 1.879...e-05
gnus-article-add-button 5 0.0003650000 7.300...e-05
gnus-earcon-display 1 0.000365 0.000365
gnus-group-name-charset 11 0.000363 3.299...e-05
gnus-group-prefixed-name 6 0.000359 5.983...e-05
org-set-tags 1 0.000355 0.000355
gnus-prin1-to-string 1 0.000352 0.000352
gnus-summary-buffer-name 2 0.000351 0.0001755
gnus-get-newsgroup-headers 1 0.000349 0.000349
gnus-cite-parse 1 0.000349 0.000349
gnus-find-method-for-group 29 0.000347 1.196...e-05
org-end-of-item 1 0.000346 0.000346
gnus-goto-colon 12 0.000338 2.816...e-05
gnus-summary-update-mark 3 0.000328 0.0001093333
gnus-newsgroup-kill-file 2 0.000324 0.000162
gnus-correct-substring 43 0.0003219999 7.488...e-06
gnus-make-directory 2 0.000314 0.000157
gnus-article-strip-banner 1 0.000305 0.000305
org-babel-hide-result-toggle-maybe 8 0.000298 3.725e-05
gnus-tool-bar-update 51 0.000291 5.705...e-06
org-clock-save-markers-for-cut-and-paste 3 0.0002890000 9.633...e-05
org-fontify-entities 124 0.0002809999 2.266...e-06
org-babel-open-src-block-result 1 0.000274 0.000274
gnus-put-text-property 28 0.0002650000 9.464...e-06
org-link-display-format 34 0.0002580000 7.588...e-06
gnus-treat-predicate 98 0.0002489999 2.540...e-06
gnus-summary-highlight-line 6 0.000247 4.116...e-05
gnus-topic-find-groups 2 0.000244 0.000122
gnus-group-set-info 5 0.000243 4.86e-05
gnus-sort-score-files 1 0.000236 0.000236
org-reduced-level 93 0.0002339999 2.516...e-06
gnus-check-backend-function 4 0.000233 5.825e-05
gnus-article-highlight-headers 1 0.000226 0.000226
gnus-group-set-timestamp 1 0.000224 0.000224
gnus-parameter-banner 1 0.000222 0.000222
gnus-list-of-unread-articles 6 0.000222 3.7e-05
gnus-topic-insert-topic-line 2 0.00022 0.00011
gnus-gather-threads-by-subject 1 0.000218 0.000218
gnus-cache-request-article 1 0.000217 0.000217
gnus-summary-make-local-variables 2 0.000217 0.0001085
gnus-group-get-parameter 20 0.0002140000 1.070...e-05
gnus-topic-find-topology 33 0.0002139999 6.484...e-06
org-at-heading-p 6 0.000209 3.483...e-05
org-get-checkbox-statistics-face 14 0.0002010000 1.435...e-05
gnus-make-hashtable 2 0.0001999999 9.999...e-05
gnus-summary-show-thread 2 0.000191 9.55e-05
gnus-score-load-files 1 0.000191 0.000191
org-move-to-column 1 0.000189 0.000189
org-on-heading-p 8 0.000185 2.3125e-05
gnus-score-load-file 2 0.000181 9.05e-05
org-cycle-level 8 0.00018 2.25e-05
gnus-group-parameter-value 26 0.00018 6.923...e-06
org-beginning-of-item 1 0.000178 0.000178
gnus-user-format-function-r 4 0.0001770000 4.425...e-05
gnus-summary-update-secondary-mark 1 0.00017 0.00017
org-at-item-p 3 0.0001670000 5.566...e-05
gnus-summary-update-line 1 0.000157 0.000157
gnus-article-display-face 1 0.000157 0.000157
gnus-replace-in-string 6 0.000148 2.466...e-05
gnus-user-format-function-attachment 4 0.000147 3.675e-05
org-add-props 35 0.000145 4.142...e-06
org-face-from-face-or-color 52 0.0001439999 2.769...e-06
gnus-parameters-get-parameter 2 0.0001400000 7.000...e-05
gnus-fetch-field 3 0.000124 4.133...e-05
gnus-group-highlight-line 1 0.000124 0.000124
gnus-article-set-window-start 2 0.0001199999 5.999...e-05
org-footnote-at-definition-p 1 0.000116 0.000116
gnus-range-difference 2 0.000114 5.7e-05
gnus-article-highlight-signature 2 0.000108 5.4e-05
gnus-backlog-enter-article 1 0.000108 0.000108
gnus-compute-unseen-list 1 0.000106 0.000106
gnus-article-search-signature 3 0.000106 3.533...e-05
gnus-get-function 7 0.000105 1.5e-05
gnus-methods-using 6 0.0001049999 1.75e-05
org-at-timestamp-p 2 0.0001040000 5.200...e-05
org-optimize-window-after-visibility-change 8 0.000104 1.3e-05
org-reinstall-markers-in-region 3 0.0001030000 3.433...e-05
org-before-change-function 27 0.0001020000 3.777...e-06
org-link-unescape 1 0.000101 0.000101
org-get-tag-face 1 9.6e-05 9.6e-05
gnus-put-text-property-excluding-characters-with-faces 6 9.400...e-05 1.566...e-05
gnus-horizontal-recenter 1 9.4e-05 9.4e-05
gnus-inverse-list-range-intersection 1 9.4e-05 9.4e-05
gnus-parse-active 1 9.4e-05 9.4e-05
gnus-score-file-name 1 9.3e-05 9.3e-05
org-get-tags-string 1 9.1e-05 9.1e-05
gnus-article-narrow-to-signature 2 9.1e-05 4.55e-05
gnus-narrow-to-page 1 9e-05 9e-05
org-check-for-hidden 1 8.7e-05 8.7e-05
gnus-file-newer-than 1 8.6e-05 8.6e-05
gnus-cite-parse-attributions 1 8.6e-05 8.6e-05
org-imenu-new-marker 34 8.599...e-05 2.529...e-06
gnus-list-range-difference 1 8.3e-05 8.3e-05
org-point-at-end-of-empty-headline 8 8.1e-05 1.0125e-05
org-invisible-p 28 8.1e-05 2.892...e-06
gnus-info-set-entry 12 7.6e-05 6.333...e-06
gnus-cite-connect-attributions 1 7.1e-05 7.1e-05
org-at-item-checkbox-p 1 7e-05 7e-05
gnus-data-compute-positions 1 6.4e-05 6.4e-05
org-gnus-no-new-news 1 6.2e-05 6.2e-05
gnus-virtual-group-p 2 6.2e-05 3.1e-05
gnus-group-timestamp-delta 1 6.1e-05 6.1e-05
gnus-summary-set-article-display-arrow 4 5.8e-05 1.45e-05
org-fix-position-after-promote 1 5.5e-05 5.5e-05
gnus-get-unread-articles-in-group 1 5.4e-05 5.4e-05
gnus-add-text-properties 10 5.300...e-05 5.300...e-06
gnus-sorted-difference 3 5.3e-05 1.766...e-05
gnus-server-equal 7 5.100...e-05 7.285...e-06
gnus-request-update-mark 1 5.1e-05 5.1e-05
gnus-id-to-header 2 5.1e-05 2.55e-05
gnus-alive-p 1 5e-05 5e-05
gnus-or 2 4.9e-05 2.45e-05
gnus-simplify-buffer-fuzzy 1 4.9e-05 4.9e-05
gnus-set-work-buffer 1 4.7e-05 4.7e-05
gnus-highlight-selected-summary 1 4.6e-05 4.6e-05
gnus-emacs-version 2 4.5e-05 2.25e-05
gnus-summary-set-display-table 1 4.4e-05 4.4e-05
gnus-cite-match-attributions 7 4.4e-05 6.285...e-06
org-link-expand-abbrev 1 4.2e-05 4.2e-05
org-cycle-item-indentation 8 4.2e-05 5.25e-06
gnus-frames-on-display-list 8 4.2e-05 5.25e-06
gnus-article-goto-header 2 3.999...e-05 1.999...e-05
org-load-modules-maybe 9 3.8e-05 4.222...e-06
gnus-ephemeral-group-p 2 3.8e-05 1.9e-05
org-extract-attributes 1 3.7e-05 3.7e-05
gnus-remove-thread 1 3.7e-05 3.7e-05
gnus-score-load-score-alist 1 3.6e-05 3.6e-05
gnus-article-get-xrefs 1 3.5e-05 3.5e-05
gnus-visual-p 11 3.4e-05 3.090...e-06
gnus-summary-make-menu-bar 1 3.4e-05 3.4e-05
gnus-group-quit-config 2 3.3e-05 1.65e-05
gnus-article-treat-ansi-sequences 1 3.3e-05 3.3e-05
gnus-async-request-fetched-article 1 3.1e-05 3.1e-05
gnus-group-remove-parameter 5 3.1e-05 6.2e-06
gnus-topic-goto-topic 3 2.999...e-05 9.999...e-06
gnus-summary-line-message-size 4 2.999...e-05 7.499...e-06
gnus-turn-off-edit-menu 1 2.7e-05 2.7e-05
gnus-cache-fully-p 1 2.7e-05 2.7e-05
gnus-article-treat-fold-newsgroups 1 2.7e-05 2.7e-05
gnus-summary-show-all-threads 1 2.7e-05 2.7e-05
gnus-mark-article-as-read 1 2.7e-05 2.7e-05
gnus-use-long-file-name 8 2.499...e-05 3.124...e-06
gnus-remove-if 8 2.499...e-05 3.124...e-06
gnus-group-method 1 2.4e-05 2.4e-05
gnus-async-prefetched-article-entry 1 2.4e-05 2.4e-05
org-remove-occur-highlights 1 2.3e-05 2.3e-05
gnus-article-treat-overstrike 1 2.2e-05 2.2e-05
gnus-kill-all-overlays 3 2.2e-05 7.333...e-06
org-skip-whitespace 3 2.100...e-05 7.000...e-06
gnus-backlog-request-article 1 2.1e-05 2.1e-05
gnus-article-mark-to-type 6 1.999...e-05 3.333...e-06
org-remove-empty-overlays-at 3 1.9e-05 6.333...e-06
gnus-summary-initial-limit 1 1.9e-05 1.9e-05
gnus-sorted-nintersection 1 1.9e-05 1.9e-05
gnus-undo-register 1 1.9e-05 1.9e-05
gnus-extract-address-components 1 1.9e-05 1.9e-05
gnus-make-overlay 6 1.8e-05 3e-06
gnus-async-prefetch-next 1 1.8e-05 1.8e-05
gnus-newsgroup-savable-name 2 1.8e-05 9e-06
org-substring-no-properties 4 1.7e-05 4.25e-06
gnus-window-to-buffer-helper 8 1.6e-05 2e-06
gnus-article-extend-url-button 1 1.6e-05 1.6e-05
gnus-id-to-thread 5 1.6e-05 3.2e-06
gnus-strip-whitespace 1 1.5e-05 1.5e-05
gnus-summary-highlight-line-0 6 1.4e-05 2.333...e-06
gnus-score-file-regexp 2 1.300...e-05 6.500...e-06
gnus-backlog-buffer 1 1.3e-05 1.3e-05
gnus-server-status 4 1.3e-05 3.25e-06
gnus-article-strip-headers-in-body 1 1.3e-05 1.3e-05
gnus-overlay-put 6 1.299...e-05 2.166...e-06
gnus-hidden-threads-configuration 1 1.2e-05 1.2e-05
gnus-article-check-hidden-text 1 1.2e-05 1.2e-05
gnus-remove-text-with-property 2 1.2e-05 6e-06
gnus-group-topic-unread 5 1.199...e-05 2.4e-06
org-region-active-p 2 1.1e-05 5.5e-06
org-item-re 3 1.1e-05 3.666...e-06
gnus-make-sort-function-1 2 1.1e-05 5.5e-06
gnus-cache-possibly-update-active 1 1.1e-05 1.1e-05
gnus-data-enter-list 1 1.1e-05 1.1e-05
gnus-root-id 1 1e-05 1e-05
gnus-windows-old-to-new 3 9.999...e-06 3.333...e-06
gnus-expand-group-parameters 2 9.999...e-06 4.999...e-06
gnus-async-set-buffer 1 9e-06 9e-06
gnus-simplify-mode-line 1 9e-06 9e-06
gnus-home-score-file 2 9e-06 4.5e-06
gnus-sorted-ndifference 2 9e-06 4.5e-06
gnus-cache-update-active 2 9e-06 4.5e-06
gnus-range-length 3 9e-06 3e-06
gnus-button-in-region-p 3 8e-06 2.666...e-06
gnus-cut-threads 2 8e-06 4e-06
gnus-add-to-sorted-list 1 8e-06 8e-06
gnus-group-new-mail 1 8e-06 8e-06
gnus-group-group-indentation 2 8e-06 4e-06
org-point-in-group 1 7e-06 7e-06
gnus-summary-limit-children 1 7e-06 7e-06
gnus-score-find-alist 1 7e-06 7e-06
gnus-agent-request-article 2 7e-06 3.5e-06
gnus-make-threads 1 7e-06 7e-06
gnus-undo-register-1 1 7e-06 7e-06
gnus-article-hide-list-identifiers 1 7e-06 7e-06
gnus-refer-article-methods 1 6e-06 6e-06
gnus-cache-update-file-total-fetched-for 1 6e-06 6e-06
gnus-backlog-setup 2 6e-06 3e-06
org-get-valid-level 1 5e-06 5e-06
gnus-summary-make-tool-bar 1 5e-06 5e-06
gnus-cache-member-of-class 1 5e-06 5e-06
gnus-cache-enter-remove-article 1 5e-06 5e-06
gnus-cite-localize 1 5e-06 5e-06
gnus-group-topic-level 2 4.999...e-06 2.499...e-06
gnus-create-hash-size 2 4.999...e-06 2.499...e-06
gnus-topic-update-unreads 2 4.999...e-06 2.499...e-06
gnus-add-wash-type 1 4e-06 4e-06
gnus-update-missing-marks 1 4e-06 4e-06
gnus-last-element 1 4e-06 4e-06
gnus-read-mark-p 1 4e-06 4e-06
gnus-group-real-prefix 1 4e-06 4e-06
gnus-restore-hidden-threads-configuration 1 4e-06 4e-06
gnus-topic-visible-p 2 4e-06 2e-06
gnus-article-hidden-text-p 1 4e-06 4e-06
gnus-unread-mark-p 1 4e-06 4e-06
gnus-sort-gathered-threads 1 3e-06 3e-06
gnus-group-group-name 1 3e-06 3e-06
gnus-data-update-list 1 3e-06 3e-06
gnus-cache-save-buffers 1 3e-06 3e-06
gnus-remove-thread-1 1 3e-06 3e-06
gnus-summary-article-pseudo-p 1 3e-06 3e-06
gnus-remove-header 1 3e-06 3e-06
gnus-article-mime-part-status 1 3e-06 3e-06
gnus-set-default-directory 1 3e-06 3e-06
gnus-sort-threads-recursive 1 3e-06 3e-06
gnus-make-thread-indent-array 1 3e-06 3e-06
gnus-cite-delete-overlays 1 2e-06 2e-06
gnus-make-local-hook 1 2e-06 2e-06
gnus-extent-start-open 1 2e-06 2e-06
gnus-group-remove-excess-properties 1 2e-06 2e-06
gnus-summary-maybe-hide-threads 1 2e-06 2e-06
--8<---------------cut here---------------end--------------->8---
The above is done on my biggest mail group (the work one), the one where it
takes more than 5 mins before seeing the mail opened.
Does this help you to help me? ;-)
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-15 21:27 ` Sébastien Vauban
@ 2010-07-16 7:50 ` Tassilo Horn
2010-07-16 11:39 ` Sébastien Vauban
0 siblings, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-16 7:50 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
Hi Sébastien,
> I've followed Nick's procedure, hoping to get even more details:
>
> --8<---------------cut here---------------start------------->8---
> Function Name Call Count Elapsed Time Average Time
> ...
> gnus-request-head 1 312.993525 312.993525
> gnus-activate-group 1 13.587475 13.587475
> gnus-group-read-group 1 7.949638 7.949638
> ...
> --8<---------------cut here---------------end--------------->8---
Looks to me that `gnus-request-head' is the culprit. Looking at the
code, I cannot see why that function is so slow. I'd try to edebug that
to see what exact part of it takes that long.
> Does this help you to help me? ;-)
We're getting closer. ;-)
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-16 7:50 ` Tassilo Horn
@ 2010-07-16 11:39 ` Sébastien Vauban
2010-07-16 18:11 ` Nick Dokos
2010-07-16 19:51 ` Sébastien Vauban
0 siblings, 2 replies; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-16 11:39 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>
>> I've followed Nick's procedure, hoping to get even more details:
>>
>> --8<---------------cut here---------------start------------->8---
>> Function Name Call Count Elapsed Time Average Time
>> ...
>> gnus-request-head 1 312.993525 312.993525
>> gnus-activate-group 1 13.587475 13.587475
>> gnus-group-read-group 1 7.949638 7.949638
>> ...
>> --8<---------------cut here---------------end--------------->8---
>
> Looks to me that `gnus-request-head' is the culprit. Looking at the code, I
> cannot see why that function is so slow. I'd try to edebug that to see what
> exact part of it takes that long.
Sorry to be such a newbie on that, but I'd understood I would have to type
`C-u C-M-x' (`edebug-defun') when on that function definition, right?
My problem is I can't access the definition, as all of Gnus is only present as
"byte-compiled" files, located in
/usr/share/emacs/23.1/lisp/
Is there a way, still, to debug the function, then, the way you intend it?
>> Does this help you to help me? ;-)
>
> We're getting closer. ;-)
Great! ;-)
Thanks for your (precious) help, anyway.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Re: Behavior of Gnus when called from an hyperlink
2010-07-16 11:39 ` Sébastien Vauban
@ 2010-07-16 18:11 ` Nick Dokos
2010-07-16 19:23 ` Sébastien Vauban
2010-07-16 19:51 ` Sébastien Vauban
1 sibling, 1 reply; 77+ messages in thread
From: Nick Dokos @ 2010-07-16 18:11 UTC (permalink / raw)
To: =?utf-8?Q?S=C3=A9bastien_Vauban?=; +Cc: nicholas.dokos, emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
> Hi Tassilo,
>
> Tassilo Horn wrote:
> > Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
> >
> >> I've followed Nick's procedure, hoping to get even more details:
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> Function Name Call Count Elapsed Time Average Time
> >> ...
> >> gnus-request-head 1 312.993525 312.993525
> >> gnus-activate-group 1 13.587475 13.587475
> >> gnus-group-read-group 1 7.949638 7.949638
> >> ...
> >> --8<---------------cut here---------------end--------------->8---
> >
> > Looks to me that `gnus-request-head' is the culprit. Looking at the code, I
> > cannot see why that function is so slow. I'd try to edebug that to see what
> > exact part of it takes that long.
>
> Sorry to be such a newbie on that, but I'd understood I would have to type
> `C-u C-M-x' (`edebug-defun') when on that function definition, right?
>
> My problem is I can't access the definition, as all of Gnus is only present as
> "byte-compiled" files, located in
>
> /usr/share/emacs/23.1/lisp/
>
> Is there a way, still, to debug the function, then, the way you intend it?
>
>
Is this because you are using the distro's package and they don't
distribute sources? There is usually a emacs-el package that installs
sources as well.
Nick
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-16 18:11 ` Nick Dokos
@ 2010-07-16 19:23 ` Sébastien Vauban
0 siblings, 0 replies; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-16 19:23 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Nick,
Nick Dokos wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> wrote:
>> Tassilo Horn wrote:
>>> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>>
>>>> I've followed Nick's procedure, hoping to get even more details:
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> Function Name Call Count Elapsed Time Average Time
>>>> ...
>>>> gnus-request-head 1 312.993525 312.993525
>>>> gnus-activate-group 1 13.587475 13.587475
>>>> gnus-group-read-group 1 7.949638 7.949638
>>>> ...
>>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> Looks to me that `gnus-request-head' is the culprit. Looking at the code,
>>> I cannot see why that function is so slow. I'd try to edebug that to see
>>> what exact part of it takes that long.
>>
>> Sorry to be such a newbie on that, but I'd understood I would have to type
>> `C-u C-M-x' (`edebug-defun') when on that function definition, right?
>>
>> My problem is I can't access the definition, as all of Gnus is only present
>> as "byte-compiled" files, located in
>>
>> /usr/share/emacs/23.1/lisp/
>>
>> Is there a way, still, to debug the function, then, the way you intend it?
>
> Is this because you are using the distro's package and they don't distribute
> sources?
Exactly. Just installed `emacs' (the virtual package) under Ubuntu 10.4, and
got Emacs 23.1.
> There is usually a emacs-el package that installs sources as well.
Of course. Did not even think at that... Thanks for pointing this out!
Now, installed `emacs23-el' (there is no `emacs-el' or so, so here I have to
explictly state a version number), and have access to the sources.
Thanks Nick.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-16 11:39 ` Sébastien Vauban
2010-07-16 18:11 ` Nick Dokos
@ 2010-07-16 19:51 ` Sébastien Vauban
2010-07-17 7:18 ` Tassilo Horn
1 sibling, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-16 19:51 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo,
> Tassilo Horn wrote:
>> Sébastien Vauban writes:
>>
>>> I've followed Nick's procedure, hoping to get even more details:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> Function Name Call Count Elapsed Time Average Time
>>> ...
>>> gnus-request-head 1 312.993525 312.993525
>>> gnus-activate-group 1 13.587475 13.587475
>>> gnus-group-read-group 1 7.949638 7.949638
>>> ...
>>> --8<---------------cut here---------------end--------------->8---
>>
>> Looks to me that `gnus-request-head' is the culprit. Looking at the code, I
>> cannot see why that function is so slow. I'd try to edebug that to see what
>> exact part of it takes that long.
>
> Sorry to be such a newbie on that, but I'd understood I would have to type
> `C-u C-M-x' (`edebug-defun') when on that function definition, right?
>
> My problem is I can't access the definition, as all of Gnus is only present
> as "byte-compiled" files, located in
>
> /usr/share/emacs/23.1/lisp/
>
> Is there a way, still, to debug the function, then, the way you intend it?
Thanks to Nick, got access to the sources, and could edebug-defun the function
`gnus-request-head':
--8<---------------cut here---------------start------------->8---
(defun gnus-request-head (article group)
"Request the head of ARTICLE in GROUP."
(let* ((gnus-command-method (gnus-find-method-for-group group))
(head (gnus-get-function gnus-command-method 'request-head t))
res clean-up)
(cond
;; Check the cache.
((and gnus-use-cache
(numberp article)
(gnus-cache-request-article article group))
(setq res (cons group article)
clean-up t))
;; Check the agent cache.
((gnus-agent-request-article article group)
(setq res (cons group article)
clean-up t))
;; Use `head' function.
((fboundp head)
(setq res (funcall head article (gnus-group-real-name group)
(nth 1 gnus-command-method))))
;; Use `article' function.
(t
(setq res (gnus-request-article article group)
clean-up t)))
(when clean-up
(save-excursion
(set-buffer nntp-server-buffer)
(goto-char (point-min))
(when (search-forward "\n\n" nil t)
(delete-region (1- (point)) (point-max)))
(nnheader-fold-continuation-lines)))
res))
--8<---------------cut here---------------end--------------->8---
When stepping with SPC, the "arrow mark" (in the left fringe) stayed 5 mins on
line 487:
--8<---------------cut here---------------start------------->8---
;; Use `head' function.
((fboundp head)
(setq res (funcall head article (gnus-group-real-name group)
> (nth 1 gnus-command-method))))
^
cursor after first paren
--8<---------------cut here---------------end--------------->8---
If I understand well, it wasted all the time evaluating
--8<---------------cut here---------------start------------->8---
(nth 1 gnus-command-method)
--8<---------------cut here---------------end--------------->8---
I can't understand anything from the above... Someone does?
Thanks in advance!
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-07-16 19:51 ` Sébastien Vauban
@ 2010-07-17 7:18 ` Tassilo Horn
2010-07-17 16:02 ` Nick Dokos
0 siblings, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-17 7:18 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
Hi Sébastien,
> When stepping with SPC, the "arrow mark" (in the left fringe) stayed 5
> mins on line 487:
>
> --8<---------------cut here---------------start------------->8---
> ;; Use `head' function.
> ((fboundp head)
> (setq res (funcall head article (gnus-group-real-name group)
>> (nth 1 gnus-command-method))))
> ^
> cursor after first paren
> --8<---------------cut here---------------end--------------->8---
>
> If I understand well, it wasted all the time evaluating
>
> --8<---------------cut here---------------start------------->8---
> (nth 1 gnus-command-method)
> --8<---------------cut here---------------end--------------->8---
>
> I can't understand anything from the above... Someone does?
Not really. Picking the second element out of a list must not take 5
minutes! What's the value of `gnus-command-method' when this happens?
One SPC before the hang, that variable is evaluated and its contents are
printed to *Messages*.
For example, checking with an org-gnus link to an article in a gmane
group, the value of `gnus-command-method' at that time was
(nntp "Gmane" (nntp-address "news.gmane.org"))
here, and picking out "Gmane" took no time at all...
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Behavior of Gnus when called from an hyperlink
2010-07-17 7:18 ` Tassilo Horn
@ 2010-07-17 16:02 ` Nick Dokos
2010-07-17 19:59 ` Sébastien Vauban
0 siblings, 1 reply; 77+ messages in thread
From: Nick Dokos @ 2010-07-17 16:02 UTC (permalink / raw)
To: Tassilo Horn, =?utf-8?Q?S=C3=A9bastien?= Vauban
Cc: nicholas.dokos, emacs-orgmode
Tassilo Horn <tassilo@member.fsf.org> wrote:
> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
> writes:
>
> Hi Sébastien,
>
> > When stepping with SPC, the "arrow mark" (in the left fringe) stayed 5
> > mins on line 487:
> >
> > --8<---------------cut here---------------start------------->8---
> > ;; Use `head' function.
> > ((fboundp head)
> > (setq res (funcall head article (gnus-group-real-name group)
> >> (nth 1 gnus-command-method))))
> > ^
> > cursor after first paren
> > --8<---------------cut here---------------end--------------->8---
> >
> > If I understand well, it wasted all the time evaluating
> >
> > --8<---------------cut here---------------start------------->8---
> > (nth 1 gnus-command-method)
> > --8<---------------cut here---------------end--------------->8---
> >
> > I can't understand anything from the above... Someone does?
>
> Not really. Picking the second element out of a list must not take 5
> minutes! What's the value of `gnus-command-method' when this happens?
> One SPC before the hang, that variable is evaluated and its contents are
> printed to *Messages*.
>
> For example, checking with an org-gnus link to an article in a gmane
> group, the value of `gnus-command-method' at that time was
>
> (nntp "Gmane" (nntp-address "news.gmane.org"))
>
> here, and picking out "Gmane" took no time at all...
>
[For some reason, I didn't receive Seb's more recent messsages, so I'm
replying to Tassilo's message to try to keep the reply in the thread.
I hope it works.]
Seb,
try single stepping to that point and evaluate the various expressions
that enter into the computation. For example,
> > ;; Use `head' function.
> > ((fboundp head)
> > (setq res (funcall head article (gnus-group-real-name group)
> >> (nth 1 gnus-command-method))))
put the cursor after the closing paren of the (nth 1 gnus-command-method)
form and type C-x C-e, after the closing paren of (gnus-group-real-name group)
and do the same and after the closing paren of the (funcall ...) and do the
same. Also perhaps after the head variable (between head and article) and
do the same. Tassilo is right of course that (nth 1 gnus-command-method)
should be trivial (unless nth has been redefined somehow and is trying to
prove the Riemann hypothesis instead :-) ) -- but the cursor might be off
by one and it's really the funcall that's taking all the time.
HTH,
Nick
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-17 16:02 ` Nick Dokos
@ 2010-07-17 19:59 ` Sébastien Vauban
2010-07-17 20:49 ` Nick Dokos
0 siblings, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-17 19:59 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Nick and Tassilo,
Nick Dokos wrote:
> Tassilo Horn <tassilo-IGUgQLVVQiRCV4ILt04nZQ@public.gmane.org> wrote:
>> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>
>>> If I understand well, it wasted all the time evaluating
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> (nth 1 gnus-command-method)
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> I can't understand anything from the above... Someone does?
>>
>> Not really. Picking the second element out of a list must not take 5
>> minutes! What's the value of `gnus-command-method' when this happens? One
>> SPC before the hang, that variable is evaluated and its contents are
>> printed to *Messages*.
>
> try single stepping to that point and evaluate the various expressions
> that enter into the computation. For example,
>
>>> ;; Use `head' function.
>>> ((fboundp head)
>>> (setq res (funcall head article (gnus-group-real-name group)
>>> -> (nth 1 gnus-command-method))))
>
> put the cursor after the closing paren of the (nth 1 gnus-command-method)
> form and type C-x C-e, after the closing paren of (gnus-group-real-name
> group) and do the same and after the closing paren of the (funcall ...) and
> do the same. Also perhaps after the head variable (between head and article)
> and do the same. Tassilo is right of course that (nth 1 gnus-command-method)
> should be trivial (unless nth has been redefined somehow and is trying to
> prove the Riemann hypothesis instead :-) ) -- but the cursor might be off by
> one and it's really the funcall that's taking all the time.
By carefully reading the article just sent by Erik (in another thread) about
Edebug, becoming aware of the cursor movements under stepping, I now can say
without error what *really* eats the time.
I effectively saw every parameter evaluated, every one after the other. Here
are the results:
- head :: nnimap-request-head
- article :: "<871vbxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org>"
- (gnus-group-real-name group) :: "INBOX.mc"
- gnus-command-method :: (nnimap "mc"
(nnimap-address "mail.missioncriticalit.com")
(nnir-search-engine imap))
- (nth 1 gnus-command-method) :: "mc"
- (funcall nnimap-request-head "<871vbxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org>" "INBOX.mc" "mc")
results... after 5 mins... in ("INBOX.mc" . 28606)
So, that's not `nth' that took the time (as previously thought), but the
`funcall'.
What does the jury thinks of that?
Thanks a lot for your remote assistance!
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Re: Behavior of Gnus when called from an hyperlink
2010-07-17 19:59 ` Sébastien Vauban
@ 2010-07-17 20:49 ` Nick Dokos
2010-07-17 21:34 ` Sébastien Vauban
0 siblings, 1 reply; 77+ messages in thread
From: Nick Dokos @ 2010-07-17 20:49 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: nicholas.dokos, emacs-orgmode
=?utf-8?Q?S=C3=A9bastien_Vauban?= <wxhgmqzgwmuf@spammotel.com> wrote:
> By carefully reading the article just sent by Erik (in another thread) about
> Edebug, becoming aware of the cursor movements under stepping, I now can say
> without error what *really* eats the time.
>
> I effectively saw every parameter evaluated, every one after the other. Here
> are the results:
>
> - head :: nnimap-request-head
> - article :: "<871vbxzo6.fsf@mundaneum.com>"
> - (gnus-group-real-name group) :: "INBOX.mc"
> - gnus-command-method :: (nnimap "mc"
> (nnimap-address "mail.missioncriticalit.com")
> (nnir-search-engine imap))
> - (nth 1 gnus-command-method) :: "mc"
> - (funcall nnimap-request-head "<871vbxzo6.fsf@mundaneum.com>" "INBOX.mc" "=
> mc")
> results... after 5 mins... in ("INBOX.mc" . 28606)
>
> So, that's not `nth' that took the time (as previously thought), but the
> `funcall'.
>
> What does the jury thinks of that?
>
You've got a few more layers of elisp to go through.
You should edebug-defun the function nnimap-request-article-part in
nnimap.el and keep going. You should also probably investigate what
would happen if you set nnimap-debug to t, after reading its docstring.
Cheers,
Nick
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-07-17 20:49 ` Nick Dokos
@ 2010-07-17 21:34 ` Sébastien Vauban
2010-07-17 22:15 ` Sébastien Vauban
0 siblings, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-17 21:34 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Nick,
Nick Dokos wrote:
> =?utf-8?Q?S=C3=A9bastien_Vauban?= <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> wrote:
>
>> - (funcall nnimap-request-head "<871vbxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org>" "INBOX.mc"
>> "mc") results... after 5 mins... in ("INBOX.mc" . 28606)
>>
>> What does the jury thinks of that?
>
> You've got a few more layers of elisp to go through.
>
> You should edebug-defun the function nnimap-request-article-part in
> nnimap.el and keep going.
Just to keep you informed, elp-instrumented nnimap, and got this:
nnimap-request-head 3 256.166102 85.388700666
nnimap-request-article-part 3 256.166004 85.388668
nnimap-request-group 2 12.306432000 6.1532160000
Your function `nnimap-request-article-part' seems the culprit, then.
> You should also probably investigate what would happen if you set
> nnimap-debug to t, after reading its docstring.
FYI, this var is always set to t, for a long time... I disabled it, and rerun
everything, but that did not impact the times (or marginally). So, ouf, it's
not the logging that takes all that time.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-07-17 21:34 ` Sébastien Vauban
@ 2010-07-17 22:15 ` Sébastien Vauban
2010-07-19 8:11 ` Tassilo Horn
0 siblings, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-17 22:15 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Nick, Tassilo,
> Nick Dokos wrote:
>> =?utf-8?Q?S=C3=A9bastien_Vauban?= wrote:
>>
>>> - (funcall nnimap-request-head
>>> "<871vbxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org>" "INBOX.mc"
>>> "mc") results... after 5 mins... in ("INBOX.mc" . 28606)
>>>
>>> What does the jury thinks of that?
>>
>> You've got a few more layers of elisp to go through.
>>
>> You should edebug-defun the function nnimap-request-article-part in
>> nnimap.el and keep going.
>
> Just to keep you informed, elp-instrumented nnimap, and got this:
>
> nnimap-request-head 3 256.166102 85.388700
> nnimap-request-article-part 3 256.166004 85.388668
> nnimap-request-group 2 12.306432000 6.15321600
>
> Your function `nnimap-request-article-part' seems the culprit, then.
Progressing, slowly. Not understanding everything from what I do...
The function `nnimap-request-article-part' gets called several times.
--8<---------------cut here---------------start------------->8---
(defun nnimap-request-article-part (article part prop &optional
group server to-buffer detail)
(when (nnimap-possibly-change-group group server)
(let ((article (if (stringp article)
(car-safe (imap-search
(format "HEADER Message-Id \"%s\"" article)
nnimap-server-buffer))
article)))
(when article
;; [...]
--8<---------------cut here---------------end--------------->8---
The first couple of times happen quickly, with `article' 140579, then 140580,
then 140581.
After that, (real) things happen:
--8<---------------cut here---------------start------------->8---
IMAP split moved mc:INBOX:140581 to INBOX.scorpios
nnimap: Updating info for nnimap+mc:INBOX.mc...done
Retrieving newsgroup: nnimap+mc:INBOX.mc...
nnimap: Updating info for nnimap+mc:INBOX.mc...done
Fetching headers for nnimap+mc:INBOX.mc...done
Scoring...done
Making sparse threads...done
Sorting threads...done
Generating summary...done
No more unread articles
--8<---------------cut here---------------end--------------->8---
and I have the top buffer displaying the subject of the linked article I'm
after. Already something...
What follows is stepping another time in the function
`nnimap-request-article-part', this time with `article'
"<871vbrxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org>" (not a number anymore).
I'm then directed in the "then" part of the "if-then-else" (testing if
`article' is a string or not).
And, then, what stops me for 5 mins is the `imap-search' call.
I guess I will have to dive that side (not now -- going to sleep). Don't know
if that gives hints yet, or not...
Thanks for your help,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-07-17 22:15 ` Sébastien Vauban
@ 2010-07-19 8:11 ` Tassilo Horn
2010-07-19 12:02 ` David Maus
0 siblings, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-19 8:11 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
Hi Sébastien,
> The function `nnimap-request-article-part' gets called several times.
>
> --8<---------------cut here---------------start------------->8---
> (defun nnimap-request-article-part (article part prop &optional
> group server to-buffer detail)
> (when (nnimap-possibly-change-group group server)
> (let ((article (if (stringp article)
> (car-safe (imap-search
> (format "HEADER Message-Id \"%s\"" article)
> nnimap-server-buffer))
> article)))
> (when article
> ;; [...]
> --8<---------------cut here---------------end--------------->8---
>
> The first couple of times happen quickly, with `article' 140579, then
> 140580, then 140581.
>
> After that, (real) things happen:
>
> --8<---------------cut here---------------start------------->8---
> IMAP split moved mc:INBOX:140581 to INBOX.scorpios
> nnimap: Updating info for nnimap+mc:INBOX.mc...done
> Retrieving newsgroup: nnimap+mc:INBOX.mc...
> nnimap: Updating info for nnimap+mc:INBOX.mc...done
> Fetching headers for nnimap+mc:INBOX.mc...done
> Scoring...done
> Making sparse threads...done
> Sorting threads...done
> Generating summary...done
> No more unread articles
> --8<---------------cut here---------------end--------------->8---
>
> and I have the top buffer displaying the subject of the linked article
> I'm after. Already something...
>
> What follows is stepping another time in the function
> `nnimap-request-article-part', this time with `article'
> "<871vbrxzo6.fsf@mundaneum.com>" (not a
> number anymore).
>
> I'm then directed in the "then" part of the "if-then-else" (testing if
> `article' is a string or not).
>
> And, then, what stops me for 5 mins is the `imap-search' call.
Hm, ok. So it seems that fetching an article by its Message-id is the
slow part. And of course, org-gnus *always* fetches by message-ids,
couse that's the message attribute you can rely on. Article numbers are
not that static: for example when moving messages to another group and
back again... (Some people do that to fill gaps in the article numbers
and fix the "wrong unread count" issue.)
> I guess I will have to dive that side (not now -- going to sleep).
> Don't know if that gives hints yet, or not...
Well, now we know that there are issues when searching for a message-id.
Please go on edebugging `imap-search'. ;-)
Please check, if that function is that slow for all message-ids or if
that's only for some. The function has a "FIXME: Should this try to use
CHARSET? -- fx", and maybe this answer has to be answered with Yes!
And check what's in the buffer that function operates on:
`nnimap-server-buffer'.
As a side-node: Since lately, my gnus hangs when I try to post to our
university's newsserver using a TLS or SSL connection. Without an
encrypted connection, it works again. I don't have a clue what's going
wrong, but somehow there's a miscommunication between gnus and the
server...
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Behavior of Gnus when called from an hyperlink
2010-07-19 8:11 ` Tassilo Horn
@ 2010-07-19 12:02 ` David Maus
2010-07-19 20:37 ` Sébastien Vauban
0 siblings, 1 reply; 77+ messages in thread
From: David Maus @ 2010-07-19 12:02 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 1149 bytes --]
Tassilo Horn wrote:
>> I guess I will have to dive that side (not now -- going to sleep).
>> Don't know if that gives hints yet, or not...
>Please check, if that function is that slow for all message-ids or if
>that's only for some. The function has a "FIXME: Should this try to use
>CHARSET? -- fx", and maybe this answer has to be answered with Yes!
I think this is not very likely: With the CHARSET argument a client
can inform the server that the search string is in a charset different
than the default 7bit ASCII (Cf. rfc3501, 6.4.4).
You could rule out the server being the culprit by performing the
search manually:
gnutls-cli --crlf --port 993 your.mail.host.here
0x1 LOGIN "user" "password"
0x2 SELECT Inbox.work
0x3 SEARCH HEADER "Message-ID" "message id w/o angle brackets"
0x4 LOGOUT
My main account uses Courier on Debian, too and search for a
particular message id within ~7000 messages is quite fast.
Couldn't find this information in the tread: Is it slow for a
particular message or slow on Inbox.work in general?
HTH,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-19 12:02 ` David Maus
@ 2010-07-19 20:37 ` Sébastien Vauban
2010-07-20 6:23 ` David Maus
` (2 more replies)
0 siblings, 3 replies; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-19 20:37 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi David, Tassilo and Nick,
David Maus wrote:
> Tassilo Horn wrote:
>> Please check, if that function is that slow for all message-ids or if
>> that's only for some. The function has a "FIXME: Should this try to use
>> CHARSET? -- fx", and maybe this answer has to be answered with Yes!
>
> I think this is not very likely: With the CHARSET argument a client can
> inform the server that the search string is in a charset different than the
> default 7bit ASCII (Cf. rfc3501, 6.4.4).
>
> You could rule out the server being the culprit by performing the search
> manually:
>
> gnutls-cli --crlf --port 993 your.mail.host.here
>
> 0x1 LOGIN "user" "password"
> 0x2 SELECT Inbox.work
> 0x3 SEARCH HEADER "Message-ID" "message id w/o angle brackets"
>
> 0x4 LOGOUT
Great idea to test that. I began with it (before going to edebug more
functions):
--8<---------------cut here---------------start------------->8---
[sva@mundaneum] />nc -vv mail imap
Connection to mail 143 port [tcp/imap2] succeeded!
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS XMAGICTRASH] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc. See COPYING for distribution information.
0x1 LOGIN "sva" "<not-shown>"
0x1 OK LOGIN Ok.
0x2 SELECT INBOX.mc
* FLAGS ($MDNSent Junk gnus-save gnus-forward NonJunk $Forwarded \Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS ($MDNSent Junk gnus-save gnus-forward NonJunk $Forwarded \* \Draft \Answered \Flagged \Deleted \Seen)] Limited
* 27072 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1097250695] Ok
* OK [MYRIGHTS "acdilrsw"] ACL
0x2 OK [READ-WRITE] Ok
0x3 SEARCH HEADER "Message-ID" "871vbrxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org"
* SEARCH 26856
0x3 OK SEARCH done.
0x3 SEARCH HEADER "Message-ID" "871vbrxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org"
* SEARCH 26856
0x3 OK SEARCH done.
0x4 LOGOUT
* BYE Courier-IMAP server shutting down
0x4 OK LOGOUT completed
[sva@mundaneum] />
--8<---------------cut here---------------end--------------->8---
Did twice the same request. Did take twice 5 mins...
> My main account uses Courier on Debian, too and search for a particular
> message id within ~7000 messages is quite fast.
In my case, the culprit seems well to be our mail server, then.
> Couldn't find this information in the tread: Is it slow for a particular
> message or slow on Inbox.work in general?
I answered this in the early beginning of the thread: time taken for opening
the link seems to be (linearly?) dependant on the size of the mail groups.
In INBOX.mc (the group for all work-related emails, containing ~27,000
emails), it takes ~5 mins to open a link from Org.
In other normally-sized groups (a couple of 100's of emails), it took a couple
of seconds (> 10 s).
Maybe a problem is that I keep all of my emails (but the spams...) since the
beginning: now, over 140,000 emails entered my INBOX -- only the spams left
it.
What would be your pieces of advice in such a case? Do I need to test
something extra? Get a local imap server? Others (like asking for fixing the
search on our Courier mail server)?
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Re: Behavior of Gnus when called from an hyperlink
2010-07-19 20:37 ` Sébastien Vauban
@ 2010-07-20 6:23 ` David Maus
2010-07-21 19:59 ` Sébastien Vauban
2010-07-20 11:50 ` Behavior of Gnus when called from an hyperlink Tassilo Horn
2010-07-20 12:08 ` Bernt Hansen
2 siblings, 1 reply; 77+ messages in thread
From: David Maus @ 2010-07-20 6:23 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 2798 bytes --]
Sébastien Vauban wrote:
>What would be your pieces of advice in such a case? Do I need to test
>something extra? Get a local imap server? Others (like asking for fixing the
>search on our Courier mail server)?
Well, IMO there might be nothing to "fix" on the server side.
Although a user might expect searches to be fast there is no directive
in the specs about the fastness of the SEARCH command. This should of
course not prevent you from dropping a mail to the IMAP server admins
about your problem to at least point at this performance issue with
large mailboxes.
At the client side I asked myself why Gnus does not use the cached
message. Some vague guesses:
> I've checked the cache; in /home/sva/Mail/cache/nnimap+me:INBOX.work, I have a
> copy of the linked email:
> -rw-r--r-- 1 sva sva 1631 2010-06-28 14:09 28606
Okay, Gnus caches the message but would have to search in all cached
messages for the message id header. "28606" might be the UID of the
message in the mailbox. To confirm this login manually and prefix the
search command with "UID"
,----
| 0x3 UID SEARCH HEADER "Message-ID" "871vbrxzo6.fsf@mundaneum.com"
`----
If this search returns 28606 then we can assume that Gnus indeed
caches by UID[1]. This means that Gnus needs to query the server what
the UID of the message with a particular message id is and could than
use the cache.
This is the point where I conclude that there can't be done anything
about it except modifying Gnus' cache mechanism.[2]
So the fall back would be: Not to keep everything in the IMAP mailbox
but expire old messages to a local folder. Here I have rule that
says: Everything older than 180 days is moved from IMAP inbox to a
local archive folder. The implications are, of course, that links to
messages older than 180 days break. To mitigate this I use Namazu[3]
to index my local archives and in case I need to follow such a broken
Org link I could open the link by performing a search for the
message-id first[4].
In the case of Gnus we might modify org-gnus-open to, say, perform a
mairix search for the message id if called with prefix and open the
message in the search result folder.
HTH,
-- David
[1] Valid strategy because message UID are quite persistent (read:
they are persistent unless a special event that we can ignore for now).
[2] Wanderlust for example does not have this problem because it keeps
an overview of the IMAP mailbox that includes among other things
message-id, uid and subject.
[3] www.namazu.org
[4] WL integrates namazu search folders so there is no need for org-wl
to perform the search, just open such a search folder.
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-20 6:23 ` David Maus
@ 2010-07-21 19:59 ` Sébastien Vauban
2010-07-22 12:31 ` Tassilo Horn
2010-07-27 6:45 ` Fixing slowness of following Gnus links to IMAP articles (was: Behavior of Gnus when called from an hyperlink) Tassilo Horn
0 siblings, 2 replies; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-21 19:59 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi David,
David Maus wrote:
> Sébastien Vauban wrote:
>> What would be your pieces of advice in such a case? Do I need to test
>> something extra? Get a local imap server? Others (like asking for fixing
>> the search on our Courier mail server)?
>
> Well, IMO there might be nothing to "fix" on the server side. Although a
> user might expect searches to be fast there is no directive in the specs
> about the fastness of the SEARCH command. This should of course not prevent
> you from dropping a mail to the IMAP server admins about your problem to at
> least point at this performance issue with large mailboxes.
>
> At the client side I asked myself why Gnus does not use the cached message.
> Some vague guesses:
>
>> I've checked the cache; in /home/sva/Mail/cache/nnimap+me:INBOX.work, I have a
>> copy of the linked email:
>
>> -rw-r--r-- 1 sva sva 1631 2010-06-28 14:09 28606
>
> Okay, Gnus caches the message but would have to search in all cached
> messages for the message id header. "28606" might be the UID of the message
> in the mailbox. To confirm this login manually and prefix the search command
> with "UID"
>
> ,----
> | 0x3 UID SEARCH HEADER "Message-ID" "871vbrxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org"
> `----
>
> If this search returns 28606 then we can assume that Gnus indeed caches by
> UID[1]. This means that Gnus needs to query the server what the UID of the
> message with a particular message id is and could than use the cache.
Your guess is right:
--8<---------------cut here---------------start------------->8---
[sva@mundaneum] />nc -vv mail imap
Connection to mail 143 port [tcp/imap2] succeeded!
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS XMAGICTRASH] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc. See COPYING for distribution information.
0x1 LOGIN "sva" "<not-displayed>"
0x1 OK LOGIN Ok.
0x2 SELECT INBOX.mc
* FLAGS ($MDNSent Junk gnus-save gnus-forward NonJunk $Forwarded \Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS ($MDNSent Junk gnus-save gnus-forward NonJunk $Forwarded \* \Draft \Answered \Flagged \Deleted \Seen)] Limited
* 27084 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1097250695] Ok
* OK [MYRIGHTS "acdilrsw"] ACL
0x2 OK [READ-WRITE] Ok
0x3 UID SEARCH HEADER "Message-ID" "871vbrxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org"
* SEARCH 28606
0x3 OK SEARCH done.
--8<---------------cut here---------------end--------------->8---
> This is the point where I conclude that there can't be done anything about
> it except modifying Gnus' cache mechanism.[2]
Do you think that would happen? Are there people aware of this, and willing
to do such a change?
Problem is I focused on Gnus for 5 years, after a careful election of the
program I would invest time in -- by reading a lot of blogs and comments on
the Web. I think I'm too bound to it now, to give a try to WL. Or you should
really insist a lot ;-)
> So the fall back would be: Not to keep everything in the IMAP mailbox but
> expire old messages to a local folder. Here I have rule that says:
> Everything older than 180 days is moved from IMAP inbox to a local archive
> folder. The implications are, of course, that links to messages older than
> 180 days break. To mitigate this I use Namazu[3] to index my local archives
> and in case I need to follow such a broken Org link I could open the link by
> performing a search for the message-id first[4].
It seems WL is better suited for this. Your solution with 180 days is a nice
work around, but I fear its impacts -- having broken links.
> In the case of Gnus we might modify org-gnus-open to, say, perform a mairix
> search for the message id if called with prefix and open the message in the
> search result folder.
Would I have to invest time on looking at mairix possibilities?
Will/Would someone work on your proposed workaround?
Thanks a lot for your help (addressed to you, and Nick, Tassilo, Bernt, in
particular for this topic),
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-21 19:59 ` Sébastien Vauban
@ 2010-07-22 12:31 ` Tassilo Horn
2010-07-26 13:17 ` David Maus
2010-07-27 6:45 ` Fixing slowness of following Gnus links to IMAP articles (was: Behavior of Gnus when called from an hyperlink) Tassilo Horn
1 sibling, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-22 12:31 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
>> This is the point where I conclude that there can't be done anything
>> about it except modifying Gnus' cache mechanism.[2]
>
> Do you think that would happen? Are there people aware of this, and
> willing to do such a change?
I'm not sure, but I think the gnus registry caches message-ids and other
information. Maybe, that could speed things up a bit.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Behavior of Gnus when called from an hyperlink
2010-07-22 12:31 ` Tassilo Horn
@ 2010-07-26 13:17 ` David Maus
2010-07-26 15:12 ` Tassilo Horn
0 siblings, 1 reply; 77+ messages in thread
From: David Maus @ 2010-07-26 13:17 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 1110 bytes --]
Tassilo Horn wrote:
>Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
>writes:
>>> This is the point where I conclude that there can't be done anything
>>> about it except modifying Gnus' cache mechanism.[2]
>>
>> Do you think that would happen? Are there people aware of this, and
>> willing to do such a change?
>I'm not sure, but I think the gnus registry caches message-ids and other
>information. Maybe, that could speed things up a bit.
After toying arround with Gnus at the weekend: Yes, there is .overview
in ~/News/agent/nnimap/<host>/<mailbox>/ that contains UIDs and (among
others) the message-id header. However it seems like there is no
function in gnus-cache.el to query the UID ("message number") for a
given message-id.
A hacky solution could be to do the lookup manually in org-gnus.el: If
the backend is nnimap and this cache file exists and a customization
variable `org-gnus-foo' is set, open the file and try to find the UID
for this message-id.
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-07-26 13:17 ` David Maus
@ 2010-07-26 15:12 ` Tassilo Horn
2010-07-26 18:47 ` Tassilo Horn
0 siblings, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-26 15:12 UTC (permalink / raw)
To: emacs-orgmode
David Maus <dmaus@ictsoc.de> writes:
Hi David,
>>I'm not sure, but I think the gnus registry caches message-ids and
>>other information. Maybe, that could speed things up a bit.
>
> After toying arround with Gnus at the weekend: Yes, there is .overview
> in ~/News/agent/nnimap/<host>/<mailbox>/ that contains UIDs and (among
> others) the message-id header. However it seems like there is no
> function in gnus-cache.el to query the UID ("message number") for a
> given message-id.
If that is true, I'd go and ask the Gnus devs for the reason. Maybe in
most cases querying the server is faster than processing the .overview
file...
> A hacky solution could be to do the lookup manually in org-gnus.el: If
> the backend is nnimap and this cache file exists and a customization
> variable `org-gnus-foo' is set, open the file and try to find the UID
> for this message-id.
Well, as a last resort that could be done, but I'm in favor of
delegating the issue to the Gnus devs. The problem will bite you in
normal Gnus usage, too. (Ok, at least when searching for/restricting
with a given message id. Scoring is also a candidate using
message-ids.)
Do you want to raise a question at ding@gnus.org, or should I do this
evening?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Fixing slowness of following Gnus links to IMAP articles (was: Behavior of Gnus when called from an hyperlink)
2010-07-21 19:59 ` Sébastien Vauban
2010-07-22 12:31 ` Tassilo Horn
@ 2010-07-27 6:45 ` Tassilo Horn
2010-07-27 20:27 ` David Maus
2010-08-03 8:01 ` Fixing slowness of following Gnus links to IMAP articles Sébastien Vauban
1 sibling, 2 replies; 77+ messages in thread
From: Tassilo Horn @ 2010-07-27 6:45 UTC (permalink / raw)
To: emacs-orgmode
Hi Sébastien,
I'm trying to add a workaround to org-gnus.el which should save the
slowness of querying the IMAP server by looking up the article number in
the group's .overview file. But since I don't have nnimap groups, we
have to play some question & answer game. ;-)
Please apply this patch and set
`org-gnus-nnimap-query-article-no-from-file' to t.
--8<---------------cut here---------------start------------->8---
diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index 7ec305b..118f088 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -55,6 +55,16 @@ negates this setting for the duration of the command."
:group 'org-link-store
:type 'boolean)
+(defcustom org-gnus-nnimap-query-article-no-from-file nil
+ "If non-nil, `org-gnus-follow-link' will try to translate
+Message-Ids to article numbers by querying the .overview file.
+Normally, this translation is done by querying the IMAP server,
+which is usually very fast. Unfortunately, some (maybe badly
+configured) IMAP servers don't support this operation quickly.
+So if following a link to a Gnus article takes ages, try setting
+this variable to `t'."
+ :group 'org-link-store
+ :type 'boolean)
;; Install the link type
(org-add-link-type "gnus" 'org-gnus-open)
@@ -173,7 +183,11 @@ If `org-store-link' was called with a prefix arg the meaning of
(cond ((and group article)
(gnus-activate-group group t)
(condition-case nil
- (let ((backend (car (gnus-find-method-for-group group))))
+ (let* ((method (gnus-find-method-for-group group))
+ (backend (car method))
+ (server (cadr method)))
+ (message "method = %s\ngroup = %s\nbackend = %s\nserver = %s"
+ method group backend server)
(cond
((eq backend 'nndoc)
(if (gnus-group-read-group t nil group)
@@ -183,6 +197,12 @@ If `org-store-link' was called with a prefix arg the meaning of
(t
(let ((articles 1)
group-opened)
+ ;; work arround IMAP servers that perform badly in
+ ;; SEARCH commands.
+ (when (and (eq backend 'nnimap)
+ org-gnus-nnimap-query-article-no-from-file)
+ (let ((headers (nnimap-retrieve-headers-from-file )))
+ (message "headers = %s" headers)))
(while (and (not group-opened)
;; stop on integer overflows
(> articles 0))
--8<---------------cut here---------------end--------------->8---
Then follow some org link to a message in a nnimap group. This will be
slow as usual, but produce some output in *Messages* that I need to go
ahead. In that buffer, there should be 4 key-value pairs "<var> =
<value>". Please poste these here.
Bye,
Tassilo
^ permalink raw reply related [flat|nested] 77+ messages in thread
* Re: Fixing slowness of following Gnus links to IMAP articles (was: Behavior of Gnus when called from an hyperlink)
2010-07-27 6:45 ` Fixing slowness of following Gnus links to IMAP articles (was: Behavior of Gnus when called from an hyperlink) Tassilo Horn
@ 2010-07-27 20:27 ` David Maus
2010-07-27 21:18 ` Nick Dokos
2010-07-28 6:36 ` Tassilo Horn
2010-08-03 8:01 ` Fixing slowness of following Gnus links to IMAP articles Sébastien Vauban
1 sibling, 2 replies; 77+ messages in thread
From: David Maus @ 2010-07-27 20:27 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 877 bytes --]
Tassilo Horn wrote:
>Hi Sébastien,
>I'm trying to add a workaround to org-gnus.el which should save the
>slowness of querying the IMAP server by looking up the article number in
>the group's .overview file. But since I don't have nnimap groups, we
>have to play some question & answer game. ;-)
>Please apply this patch and set
>`org-gnus-nnimap-query-article-no-from-file' to t.
The patch does not work: It calls `nnimap-retrieve-headers-from-file'
without the required arguments (group server) and the headers are not
fetched because `nnimap-retrieve-headers-from-file' looks for a NOV
cache file, not .overview.
Alas: I couldn't figure out how to enable NOV cache for my nnimap
group. Setting `nnimap-nov-is-evil' to nil didn't help.
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Fixing slowness of following Gnus links to IMAP articles (was: Behavior of Gnus when called from an hyperlink)
2010-07-27 20:27 ` David Maus
@ 2010-07-27 21:18 ` Nick Dokos
2010-07-28 6:50 ` Fixing slowness of following Gnus links to IMAP articles Tassilo Horn
2010-07-28 6:36 ` Tassilo Horn
1 sibling, 1 reply; 77+ messages in thread
From: Nick Dokos @ 2010-07-27 21:18 UTC (permalink / raw)
To: David Maus; +Cc: Tassilo Horn, nicholas.dokos, emacs-orgmode
David Maus <dmaus@ictsoc.de> wrote:
> ...
> Alas: I couldn't figure out how to enable NOV cache for my nnimap
> group. Setting `nnimap-nov-is-evil' to nil didn't help.
>
[Warning: I know very little about gnus, perhaps just enough
to be dangerous and you probably already know all this, but just
in case... The bit that caught my attention is the slowness of
the uid search command on some versions of Courier, which seems...
related.]
Perhaps this bit from the Gnus docs might help?
,----
| `nnimap-nov-is-evil'
| Never generate or use a local NOV database. Defaults to the value
| of `gnus-agent'.
|
| Using a NOV database usually makes header fetching much faster,
| but it uses the `UID SEARCH UID' command, which is very slow on
| some servers (notably some versions of Courier). Since the Gnus
| Agent caches the information in the NOV database without using the
| slow command, this variable defaults to true if the Agent is in
| use, and false otherwise.
`----
Seems to have something to do with the agent? In my case, both
gnus-agent
and
gnus-agent-cache
are t, but I have no idea how to set up nnimap, so I can't check
any of this.
One-of-these-days-I'll-really-understand-gnus-but-not-soon-ly yours,
Nick
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Fixing slowness of following Gnus links to IMAP articles
2010-07-27 21:18 ` Nick Dokos
@ 2010-07-28 6:50 ` Tassilo Horn
2010-07-29 7:33 ` David Maus
0 siblings, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-28 6:50 UTC (permalink / raw)
To: emacs-orgmode
Nick Dokos <nicholas.dokos@hp.com> writes:
Hi Nick,
> [Warning: I know very little about gnus, perhaps just enough
> to be dangerous and you probably already know all this, but just
> in case... The bit that caught my attention is the slowness of
> the uid search command on some versions of Courier, which seems...
> related.]
Yeah, just a minute ago when replying to David I also stumbled across
that paragraph. So maybe we are trying to replace one extremely long
running command which only occurs when following links (or searching for
Message-Ids) with a constant slowness in normal operation. But let's
try it out.
> Perhaps this bit from the Gnus docs might help?
>
> ,----
> | `nnimap-nov-is-evil'
> | Never generate or use a local NOV database. Defaults to the value
> | of `gnus-agent'.
> |
> | Using a NOV database usually makes header fetching much faster,
> | but it uses the `UID SEARCH UID' command, which is very slow on
> | some servers (notably some versions of Courier). Since the Gnus
> | Agent caches the information in the NOV database without using the
> | slow command, this variable defaults to true if the Agent is in
> | use, and false otherwise.
> `----
>
> Seems to have something to do with the agent? In my case, both
>
> gnus-agent
> and
> gnus-agent-cache
>
> are t, but I have no idea how to set up nnimap, so I can't check any
> of this.
It should be as easy as:
(add-to-list 'gnus-secondary-select-methods
'(nnimap "MyAccount"
(nnimap-address "my-imap.server.com")))
and putting your user/password for my-imap.server.com into your
~/.authinfo. You might want to put a (nnimap-stream tls) into the
method spec above if the server supports TLS (or ssl for SSL).
> One-of-these-days-I'll-really-understand-gnus-but-not-soon-ly yours,
Nobody understands Gnus. ;-)
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Re: Fixing slowness of following Gnus links to IMAP articles
2010-07-28 6:50 ` Fixing slowness of following Gnus links to IMAP articles Tassilo Horn
@ 2010-07-29 7:33 ` David Maus
2010-07-29 18:06 ` Tassilo Horn
0 siblings, 1 reply; 77+ messages in thread
From: David Maus @ 2010-07-29 7:33 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 2623 bytes --]
Tassilo Horn wrote:
>Nick Dokos <nicholas.dokos@hp.com> writes:
>Hi Nick,
>> [Warning: I know very little about gnus, perhaps just enough
>> to be dangerous and you probably already know all this, but just
>> in case... The bit that caught my attention is the slowness of
>> the uid search command on some versions of Courier, which seems...
>> related.]
>Yeah, just a minute ago when replying to David I also stumbled across
>that paragraph. So maybe we are trying to replace one extremely long
>running command which only occurs when following links (or searching for
>Message-Ids) with a constant slowness in normal operation. But let's
>try it out.
Finally I got a novcache:
,----[ gnus.el ]
| ;;; Experimental Gnus setup
|
| (setq gnus-select-method '(nntp "news.gmane.org"))
| (setq gnus-secondary-select-methods
| '((nnimap "localhost"
| (nnimap-address "localhost")
| (nnimap-server-port 993)
| (nnimap-stream ssl))))
|
| (setq nnimap-nov-is-evil nil)
| (setq gnus-cache-enter-articles '(ticked dormant unread read))
|
| (setq org-gnus-nnimap-query-article-no-from-file t)
`----
Now the strange thing is that the novcache file in ~/News/overview is
100% identical to .overview in ~/News/agent
,----
| dmaus@t41 ~/News % md5sum overview/nnimap/localhost/INBOX/1280089306/novcache agent/nnimap/localhost/INBOX/.overview
| b4a78e25a064f0c260f76080a00991cd overview/nnimap/localhost/INBOX/1280089306/novcache
| b4a78e25a064f0c260f76080a00991cd agent/nnimap/localhost/INBOX/.overview
| dmaus@t41 ~/News %
`----
Anyway: `nnimap-retrieve-headers-from-file' does not work as expected.
First, it requires the group parameter without backend and server
prefix (e.g. "INBOX" instead of "nnimap+localhost:INBOX".
Second it would return a cons (min-UID . max-UID). That wouldn't help
us, would it?
Third and amazingly my novcache seems to be corrupt right after
creation: `nnimap-retrieve-headers-from-file' does not get the maximum
UID but reads "INBOX" (?!) -- A string that looks kind of a header
information for nov -- and not "18753" what is the highest UID in the
mailbox.
Last line of the cache:
(it's a local copy of wanderlust general newsgroup accessed via IMAP)
,----
| 18753 Re: checking imap folder unplugged Yoichi NAKAYAMA <yoichi@eken.phys.nagoya-u.ac.jp> Sun, 13 Oct 2002 10:19:13 +0900 <wyadljm8z2.wl@eken3.eken.phys.nagoya-u.ac.jp> <87ptvqcd9p.wl@eken.phys.nagoya-u.ac.jp> 4424 13 Xref: t41.ictsoc.de INBOX:18753 Newsgroups: gmane.mail.wanderlust.general.japanese
`----
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Fixing slowness of following Gnus links to IMAP articles
2010-07-29 7:33 ` David Maus
@ 2010-07-29 18:06 ` Tassilo Horn
2010-07-30 20:03 ` Sébastien Vauban
2010-08-01 8:38 ` David Maus
0 siblings, 2 replies; 77+ messages in thread
From: Tassilo Horn @ 2010-07-29 18:06 UTC (permalink / raw)
To: emacs-orgmode
David Maus <dmaus@ictsoc.de> writes:
Hi David,
> Finally I got a novcache:
Congratulations! ;-)
> ,----[ gnus.el ]
> | ;;; Experimental Gnus setup
> |
> | (setq gnus-select-method '(nntp "news.gmane.org"))
> | (setq gnus-secondary-select-methods
> | '((nnimap "localhost"
> | (nnimap-address "localhost")
> | (nnimap-server-port 993)
> | (nnimap-stream ssl))))
> |
> | (setq nnimap-nov-is-evil nil)
> | (setq gnus-cache-enter-articles '(ticked dormant unread read))
> |
> | (setq org-gnus-nnimap-query-article-no-from-file t)
> `----
>
> Now the strange thing is that the novcache file in ~/News/overview is
> 100% identical to .overview in ~/News/agent
Two are better than one! (I have no idea why.)
> ,----
> | dmaus@t41 ~/News % md5sum overview/nnimap/localhost/INBOX/1280089306/novcache agent/nnimap/localhost/INBOX/.overview
> | b4a78e25a064f0c260f76080a00991cd overview/nnimap/localhost/INBOX/1280089306/novcache
> | b4a78e25a064f0c260f76080a00991cd agent/nnimap/localhost/INBOX/.overview
> | dmaus@t41 ~/News %
> `----
>
> Anyway: `nnimap-retrieve-headers-from-file' does not work as expected.
> First, it requires the group parameter without backend and server
> prefix (e.g. "INBOX" instead of "nnimap+localhost:INBOX".
I've expected that.
> Second it would return a cons (min-UID . max-UID). That wouldn't help
> us, would it?
What an appropriately named function that is. ;-) No, that wouldn't
help. But its code could be stolen to write and own function to insert
the right NOV file in a temp buffer, to search for the message-id.
Something like that:
--8<---------------cut here---------------start------------->8---
(defun org-gnus-nnimap-get-article-number (group server message-id)
(with-current-buffer nntp-server-buffer
(let ((nov (nnimap-group-overview-filename group server)))
(when (file-exists-p nov)
(mm-insert-file-contents nov)
(set-buffer-modified-p nil)
(when (search-forward message-id nil t)
(goto-char (line-beginning-position))
(read (current-buffer)))))))
--8<---------------cut here---------------end--------------->8---
That function is totally untested, but might do what it should.
> Third and amazingly my novcache seems to be corrupt right after
> creation: `nnimap-retrieve-headers-from-file' does not get the maximum
> UID but reads "INBOX" (?!) -- A string that looks kind of a header
> information for nov -- and not "18753" what is the highest UID in the
> mailbox.
>
> Last line of the cache:
> (it's a local copy of wanderlust general newsgroup accessed via IMAP)
>
> ,----
> | 18753 Re: checking imap folder unplugged Yoichi NAKAYAMA <yoichi@eken.phys.nagoya-u.ac.jp> Sun, 13 Oct 2002 10:19:13 +0900 <wyadljm8z2.wl@eken3.eken.phys.nagoya-u.ac.jp> <87ptvqcd9p.wl@eken.phys.nagoya-u.ac.jp> 4424 13 Xref: t41.ictsoc.de INBOX:18753 Newsgroups: gmane.mail.wanderlust.general.japanese
> `----
Really strange. Maybe the corruption comes from replacing TABs by
spaces using some home-brewn auto-replace-all-tabs-with-spaces function?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Fixing slowness of following Gnus links to IMAP articles
2010-07-29 18:06 ` Tassilo Horn
@ 2010-07-30 20:03 ` Sébastien Vauban
2010-08-15 18:52 ` David Maus
2010-08-01 8:38 ` David Maus
1 sibling, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-30 20:03 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo and David,
Tassilo Horn wrote:
> David Maus <dmaus-lYycHbxpNtazQB+pC5nmwQ@public.gmane.org> writes:
>>
>> Now the strange thing is that the novcache file in ~/News/overview is
>> 100% identical to .overview in ~/News/agent
>
> Two are better than one! (I have no idea why.)
>
>> ,----
>> | dmaus@t41 ~/News % md5sum overview/nnimap/localhost/INBOX/1280089306/novcache agent/nnimap/localhost/INBOX/.overview
>> | b4a78e25a064f0c260f76080a00991cd overview/nnimap/localhost/INBOX/1280089306/novcache
>> | b4a78e25a064f0c260f76080a00991cd agent/nnimap/localhost/INBOX/.overview
>> | dmaus@t41 ~/News %
>> `----
>>
>> Anyway: `nnimap-retrieve-headers-from-file' does not work as expected.
>> First, it requires the group parameter without backend and server
>> prefix (e.g. "INBOX" instead of "nnimap+localhost:INBOX".
>
> I've expected that.
>
>> Second it would return a cons (min-UID . max-UID). That wouldn't help
>> us, would it?
>
> What an appropriately named function that is. ;-) No, that wouldn't
> help. But its code could be stolen to write and own function to insert
> the right NOV file in a temp buffer, to search for the message-id.
> Something like that:
>
> (defun org-gnus-nnimap-get-article-number (group server message-id)
> (with-current-buffer nntp-server-buffer
> (let ((nov (nnimap-group-overview-filename group server)))
> (when (file-exists-p nov)
> (mm-insert-file-contents nov)
> (set-buffer-modified-p nil)
> (when (search-forward message-id nil t)
> (goto-char (line-beginning-position))
> (read (current-buffer)))))))
>
> That function is totally untested, but might do what it should.
Just to say I'm back online -- after a week holiday and an almost nil access
to the newsgroups.
Thanks a lot for trying to get Gnus better behaving in face of slow servers
like Courier...
Do "you" want me to test something special to move things forward?
FYI, here is the state (for months or years) of the 3 vars you mentionned in
the thread:
- nnimap-nov-is-evil is nil
- gnus-agent is nil
- gnus-agent-cache is t
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Fixing slowness of following Gnus links to IMAP articles
2010-07-30 20:03 ` Sébastien Vauban
@ 2010-08-15 18:52 ` David Maus
2010-09-08 15:09 ` Sébastien Vauban
0 siblings, 1 reply; 77+ messages in thread
From: David Maus @ 2010-08-15 18:52 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
Sébastien Vauban wrote:
>Just to say I'm back online -- after a week holiday and an almost nil access
>to the newsgroups.
>Thanks a lot for trying to get Gnus better behaving in face of slow servers
>like Courier...
>Do "you" want me to test something special to move things forward?
Okay, could you try the attached patch? It is based on current master
and tries to look up the article number (uid) in NOVCACHE and falls
back to UID SEARCH when the message is not cached.
To make a message enter Gnus' cache you might to modify
`gnus-cache-enter-articles'. The cache setting I used to test the
patch are:
,----[ gnus.el ]
| (setq nnimap-nov-is-evil nil)
| (setq gnus-use-cache t)
| (setq gnus-cache-enter-articles '(ticked dormant unread read))
`----
NOTE: This patch is deliberately not attached as text/plain to avoid
the patchtracker catching it (no proper commit message and all).
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #2: 0001-Try-fix-1.patch --]
[-- Type: application/octet-stream, Size: 2955 bytes --]
From 1f48ce1fad323503c6c7f79c5cd7c2b3b05370ba Mon Sep 17 00:00:00 2001
From: David Maus <dmaus@ictsoc.de>
Date: Sun, 15 Aug 2010 20:41:59 +0200
Subject: [PATCH] Try fix 1.
---
lisp/org-gnus.el | 38 +++++++++++++++++++++++++++++++++++++-
1 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index 10a0426..f98256f 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -54,12 +54,40 @@ negates this setting for the duration of the command."
:group 'org-link-store
:type 'boolean)
+(defcustom org-gnus-nnimap-query-article-no-from-file t
+ "If non-nil, `org-gnus-follow-link' will try to translate
+Message-Ids to article numbers by querying the .overview file.
+Normally, this translation is done by querying the IMAP server,
+which is usually very fast. Unfortunately, some (maybe badly
+configured) IMAP servers don't support this operation quickly.
+So if following a link to a Gnus article takes ages, try setting
+this variable to `t'."
+ :group 'org-link-store
+ :type 'boolean)
+
+
;; Install the link type
(org-add-link-type "gnus" 'org-gnus-open)
(add-hook 'org-store-link-functions 'org-gnus-store-link)
;; Implementation
+(defun org-gnus-nnimap-cached-article-number (group server message-id)
+ "Return cached article number (uid) of message in GROUP on SERVER.
+MESSAGE-ID is the message-id header field that identifies the
+message. If the uid is not cached, return nil."
+ (with-temp-buffer
+ (let ((nov (nnimap-group-overview-filename group server)))
+ (when (file-exists-p nov)
+ (mm-insert-file-contents nov)
+ (set-buffer-modified-p nil)
+ (goto-char (point-min))
+ (catch 'found
+ (while (search-forward message-id nil t)
+ (let ((hdr (split-string (thing-at-point 'line) "\t")))
+ (if (string= (nth 4 hdr) message-id)
+ (throw 'found (nth 0 hdr))))))))))
+
(defun org-gnus-group-link (group)
"Create a link to the Gnus group GROUP.
If GROUP is a newsgroup and `org-gnus-prefer-web-links' is
@@ -171,7 +199,9 @@ If `org-store-link' was called with a prefix arg the meaning of
(cond ((and group article)
(gnus-activate-group group t)
(condition-case nil
- (let ((backend (car (gnus-find-method-for-group group))))
+ (let* ((method (gnus-find-method-for-group group))
+ (backend (car method))
+ (server (cadr method)))
(cond
((eq backend 'nndoc)
(if (gnus-group-read-group t nil group)
@@ -181,6 +211,12 @@ If `org-store-link' was called with a prefix arg the meaning of
(t
(let ((articles 1)
group-opened)
+ (when (and (eq backend 'nnimap)
+ org-gnus-nnimap-query-article-no-from-file)
+ (setq article
+ (or (org-gnus-nnimap-cached-article-number
+ (nth 1 (split-string group ":"))
+ server (concat "<" article ">")) article)))
(while (and (not group-opened)
;; stop on integer overflows
(> articles 0))
--
1.7.1
[-- Attachment #3: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply related [flat|nested] 77+ messages in thread
* Re: Fixing slowness of following Gnus links to IMAP articles
2010-08-15 18:52 ` David Maus
@ 2010-09-08 15:09 ` Sébastien Vauban
2010-09-08 19:08 ` David Maus
0 siblings, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-09-08 15:09 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi David,
David Maus wrote:
> Sébastien Vauban wrote:
>> Thanks a lot for trying to get Gnus better behaving in face of slow servers
>> like Courier...
>>
>> Do "you" want me to test something special to move things forward?
>
> Okay, could you try the attached patch? It is based on current master and
> tries to look up the article number (uid) in NOVCACHE and falls back to UID
> SEARCH when the message is not cached.
Sorry to have awaited so long. Needless to say there are not enough hours in a
day. But, being in Org, I knew I'd do it one day! ;-)
> To make a message enter Gnus' cache you might to modify
> `gnus-cache-enter-articles'. The cache setting I used to test the patch are:
>
> ,----[ gnus.el ]
> | (setq nnimap-nov-is-evil nil)
> | (setq gnus-use-cache t)
> | (setq gnus-cache-enter-articles '(ticked dormant unread read))
> `----
I already had these set to exactly those values...
> NOTE: This patch is deliberately not attached as text/plain to avoid
> the patchtracker catching it (no proper commit message and all).
The results of the jury are...
...
...
...
it just perfectly *works*! Great, great feature... Thanks a lot.
FYI, here are the results of my first invocation of it:
--8<---------------cut here---------------start------------->8---
org-open-at-point 1 18.586562 18.586562
org-gnus-open 1 18.584601 18.584601
org-gnus-follow-link 1 18.584491 18.584491
org-gnus-nnimap-cached-article-number 1 0.092368 0.092368
org-resolve-clocks-if-idle 1 0.006299 0.006299
org-user-idle-seconds 1 0.006273 0.006273
org-x11-idle-seconds 1 0.00626 0.00626
org-in-regexp 2 0.000723 0.0003615
org-clock-update-mode-line 1 0.000663 0.000663
org-footnote-at-reference-p 1 0.000644 0.000644
org-babel-open-src-block-result 1 0.00038 0.00038
org-babel-get-src-block-info 1 0.000362 0.000362
org-clock-notify-once-if-expired 1 0.000271 0.000271
org-babel-where-is-src-block-head 1 0.00027 0.00027
org-clock-get-clock-string 1 0.000262 0.000262
org-activate-bracket-links 4 0.000246 6.15e-05
org-clock-get-clocked-time 2 0.000221 0.0001105
org-activate-plain-links 4 0.0001860000 4.650...e-05
org-unfontify-region 2 0.00018 9e-05
org-float-time 4 0.000176 4.4e-05
org-match-string-no-properties 3 0.000123 4.1e-05
org-footnote-at-definition-p 1 0.000121 0.000121
org-link-unescape 1 0.000117 0.000117
org-propertize 4 0.000115 2.875e-05
org-remove-flyspell-overlays-in 4 0.000104 2.6e-05
org-activate-tags 2 0.0001009999 5.049...e-05
org-substring-no-properties 4 9.7e-05 2.425e-05
org-before-change-function 40 9.299...e-05 2.324...e-06
org-activate-footnote-links 2 8.5e-05 4.25e-05
org-gnus-no-new-news 1 8e-05 8e-05
org-hh:mm-string-to-minutes 2 7.6e-05 3.8e-05
org-at-timestamp-p 1 6.1e-05 6.1e-05
org-link-expand-abbrev 1 4.4e-05 4.4e-05
org-extract-attributes 1 4.4e-05 4.4e-05
org-fontify-meta-lines-and-blocks 2 3.6e-05 1.8e-05
org-do-emphasis-faces 2 3.4e-05 1.7e-05
org-on-heading-p 1 3.2e-05 3.2e-05
org-hide-wide-columns 2 2.600...e-05 1.300...e-05
org-activate-dates 2 2.499...e-05 1.249...e-05
org-rear-nonsticky-at 8 2.300...e-05 2.875...e-06
org-remove-font-lock-display-properties 2 2.3e-05 1.15e-05
org-activate-angle-links 2 2.3e-05 1.15e-05
org-clocking-p 1 1.9e-05 1.9e-05
org-font-lock-add-tag-faces 2 1.4e-05 7e-06
org-activate-code 2 1.300...e-05 6.500...e-06
org-font-lock-add-priority-faces 2 1.2e-05 6e-06
org-remove-occur-highlights 1 1.1e-05 1.1e-05
org-add-props 1 9e-06 9e-06
org-load-modules-maybe 1 7e-06 7e-06
org-raise-scripts 2 4.999...e-06 2.499...e-06
org-do-latex-and-special-faces 2 4.999...e-06 2.499...e-06
org-fontify-entities 2 4.999...e-06 2.499...e-06
org-activate-target-links 2 4.999...e-06 2.499...e-06
org-clocking-buffer 1 4e-06 4e-06
org-font-lock-hook 2 4e-06 2e-06
--8<---------------cut here---------------end--------------->8---
So, read 18 seconds instead of the 5 minutes I had before the patch. From
totally unusable, the feature becomes completely usable...
From different tests I've made in my huge work folder (~ 29,300 emails as of
today), the average time is around 14 seconds. Excellent.
I'm excited about using this all the time now... Will you make that part of
the master?
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Fixing slowness of following Gnus links to IMAP articles
2010-09-08 15:09 ` Sébastien Vauban
@ 2010-09-08 19:08 ` David Maus
2010-09-08 21:42 ` Sébastien Vauban
0 siblings, 1 reply; 77+ messages in thread
From: David Maus @ 2010-09-08 19:08 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 376 bytes --]
Sébastien Vauban wrote:
>it just perfectly *works*! Great, great feature... Thanks a lot.
Sweet!
>I'm excited about using this all the time now... Will you make that part of
>the master?
Sure, its on my list and will be pushed tomorrow (i think).
HTH,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Fixing slowness of following Gnus links to IMAP articles
2010-09-08 19:08 ` David Maus
@ 2010-09-08 21:42 ` Sébastien Vauban
2010-09-09 12:19 ` David Maus
0 siblings, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-09-08 21:42 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi David,
David Maus wrote:
> Sébastien Vauban wrote:
>> it just perfectly *works*! Great, great feature... Thanks a lot.
>
> Sweet!
I must add that 14 seconds is the average time for my huge folder. For folder
of more traditional sizes (less emails), it's more or less instantaneous...
>> I'm excited about using this all the time now... Will you make that part of
>> the master?
>
> Sure, its on my list and will be pushed tomorrow (i think).
Thanks...
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Fixing slowness of following Gnus links to IMAP articles
2010-09-08 21:42 ` Sébastien Vauban
@ 2010-09-09 12:19 ` David Maus
2010-10-01 0:53 ` Matt Lundin
0 siblings, 1 reply; 77+ messages in thread
From: David Maus @ 2010-09-09 12:19 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 606 bytes --]
Sébastien Vauban wrote:
>Hi David,
>David Maus wrote:
>> Sébastien Vauban wrote:
>>> it just perfectly *works*! Great, great feature... Thanks a lot.
>>
>> Sweet!
>I must add that 14 seconds is the average time for my huge folder. For folder
>of more traditional sizes (less emails), it's more or less instantaneous...
I suppose (from the timing of the functions) that what takes that long
is Gnus building the view of the folder.
>Thanks...
Just pushed to master.
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Fixing slowness of following Gnus links to IMAP articles
2010-09-09 12:19 ` David Maus
@ 2010-10-01 0:53 ` Matt Lundin
2010-10-11 18:33 ` David Maus
0 siblings, 1 reply; 77+ messages in thread
From: Matt Lundin @ 2010-10-01 0:53 UTC (permalink / raw)
To: David Maus; +Cc: Sébastien Vauban, emacs-orgmode
Hi David,
David Maus <dmaus@ictsoc.de> writes:
> Sébastien Vauban wrote:
>>Hi David,
>
>>David Maus wrote:
>>> Sébastien Vauban wrote:
>>>> it just perfectly *works*! Great, great feature... Thanks a lot.
>>>
>>> Sweet!
>
>>I must add that 14 seconds is the average time for my huge folder. For folder
>>of more traditional sizes (less emails), it's more or less instantaneous...
>
> I suppose (from the timing of the functions) that what takes that long
> is Gnus building the view of the folder.
>
> Just pushed to master.
>
This commit is incompatible with development Gnus (and, therefore, the
Gnus that will be released with Emacs 24). Going forward, nnimap.el no
longer has the function nnimap-group-overview-filename. Thus, with the
default settings and development gnus, org-follow-link fails on gnus
links to imap links.
For the time being, could we set the default value of
org-gnus-nnimap-query-article-no-from-file to nil? This would allow
users of Courier servers and Emacs 23 to gain the speed benefits without
causing unexpected problems for users of development Gnus.
For reference, here are the full commit details:
--8<---------------cut here---------------start------------->8---
commit 6d7b15cf9ff4025c2670e48c08f52e12a8b5928b
Author: David Maus <dmaus@ictsoc.de>
Date: Thu Sep 9 14:16:22 2010 +0200
Mitigate access to messages on slow IMAP servers.
* org-gnus.el (org-gnus-nnimap-query-article-no-from-file): New
customization variable.
(org-gnus-nnimap-cached-article-number): New function.
(org-gnus-follow-link): Try to fetch cached article number of
message-id.
Some IMAP servers (e.g. Courier) are slow when searching for a message
by its message id header field. Because article numbers in IMAP
mailboxes are persistent UIDs, we can try to look up the UID of a IMAP
message in Gnus' cache for the mailbox in question and skip the slow
search on the server.
The problem with slow server was reported by S?bastien Vauban and the
patch is based on the work of Tassilo Horn.
--8<---------------cut here---------------end--------------->8---
Best,
Matt
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Fixing slowness of following Gnus links to IMAP articles
2010-10-01 0:53 ` Matt Lundin
@ 2010-10-11 18:33 ` David Maus
0 siblings, 0 replies; 77+ messages in thread
From: David Maus @ 2010-10-11 18:33 UTC (permalink / raw)
To: Matt Lundin; +Cc: David Maus, emacs-orgmode, Sébastien Vauban
[-- Attachment #1.1: Type: text/plain, Size: 793 bytes --]
At Thu, 30 Sep 2010 20:53:01 -0400,
Matt Lundin wrote:
> This commit is incompatible with development Gnus (and, therefore, the
> Gnus that will be released with Emacs 24). Going forward, nnimap.el no
> longer has the function nnimap-group-overview-filename. Thus, with the
> default settings and development gnus, org-follow-link fails on gnus
> links to imap links.
>
> For the time being, could we set the default value of
> org-gnus-nnimap-query-article-no-from-file to nil? This would allow
> users of Courier servers and Emacs 23 to gain the speed benefits without
> causing unexpected problems for users of development Gnus.
Thanks for pointing this out. It is set to nil now.
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Fixing slowness of following Gnus links to IMAP articles
2010-07-29 18:06 ` Tassilo Horn
2010-07-30 20:03 ` Sébastien Vauban
@ 2010-08-01 8:38 ` David Maus
1 sibling, 0 replies; 77+ messages in thread
From: David Maus @ 2010-08-01 8:38 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 1644 bytes --]
Tassilo Horn wrote:
>> Second it would return a cons (min-UID . max-UID). That wouldn't help
>> us, would it?
>What an appropriately named function that is. ;-) No, that wouldn't
>help. But its code could be stolen to write and own function to insert
>the right NOV file in a temp buffer, to search for the message-id.
>Something like that:
Well, using `nnimap-retrieve-headers-from-file' would work because it
loads the cache into `nntp-server-buffer'. But it turned out that my
problem with the garbled cache is a bug in this function: It doesn't
erase the buffer before inserting the cache file and the buffer is not
empty (bug report filed).
So we need our own function. A slight modification of yours:
--8<---------------cut here---------------start------------->8---
(defun org-gnus-nnimap-get-article-number (group server message-id)
(with-temp-buffer
(let ((nov (nnimap-group-overview-filename group server)))
(when (file-exists-p nov)
(mm-insert-file-contents nov)
(set-buffer-modified-p nil)
(goto-char (point-min))
(catch 'found
(while (search-forward message-id nil t)
(let ((hdr (split-string (thing-at-point 'line) "\t")))
(if (string= (nth 4 hdr) message-id)
(throw 'found (number-to-string (nth 0 hdr)))))))))))
--8<---------------cut here---------------start------------->8---
- the message-id might also appear in a in-reply-to oder references
field
- use a temp buffer to avoid possible confusion for Gnus
(e.g. content of nntp-server-buffer changed outside Gnus)
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Fixing slowness of following Gnus links to IMAP articles
2010-07-27 20:27 ` David Maus
2010-07-27 21:18 ` Nick Dokos
@ 2010-07-28 6:36 ` Tassilo Horn
2010-07-31 8:34 ` Patchwork: Patch 176 Accepted Bastien Guerry
1 sibling, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-28 6:36 UTC (permalink / raw)
To: emacs-orgmode
David Maus <dmaus@ictsoc.de> writes:
Hi David,
>>I'm trying to add a workaround to org-gnus.el which should save the
>>slowness of querying the IMAP server by looking up the article number
>>in the group's .overview file. But since I don't have nnimap groups,
>>we have to play some question & answer game. ;-)
>
>>Please apply this patch and set
>>`org-gnus-nnimap-query-article-no-from-file' to t.
>
> The patch does not work: It calls `nnimap-retrieve-headers-from-file'
> without the required arguments (group server)
Argh, stupid me! Here's a corrected patch.
--8<---------------cut here---------------start------------->8---
diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el
index 7ec305b..7a339cd 100644
--- a/lisp/org-gnus.el
+++ b/lisp/org-gnus.el
@@ -55,6 +55,16 @@ negates this setting for the duration of the command."
:group 'org-link-store
:type 'boolean)
+(defcustom org-gnus-nnimap-query-article-no-from-file nil
+ "If non-nil, `org-gnus-follow-link' will try to translate
+Message-Ids to article numbers by querying the .overview file.
+Normally, this translation is done by querying the IMAP server,
+which is usually very fast. Unfortunately, some (maybe badly
+configured) IMAP servers don't support this operation quickly.
+So if following a link to a Gnus article takes ages, try setting
+this variable to `t'."
+ :group 'org-link-store
+ :type 'boolean)
;; Install the link type
(org-add-link-type "gnus" 'org-gnus-open)
@@ -173,7 +183,11 @@ If `org-store-link' was called with a prefix arg the meaning of
(cond ((and group article)
(gnus-activate-group group t)
(condition-case nil
- (let ((backend (car (gnus-find-method-for-group group))))
+ (let* ((method (gnus-find-method-for-group group))
+ (backend (car method))
+ (server (cadr method)))
+ (message "method = %s\ngroup = %s\nbackend = %s\nserver = %s"
+ method group backend server)
(cond
((eq backend 'nndoc)
(if (gnus-group-read-group t nil group)
@@ -183,6 +197,12 @@ If `org-store-link' was called with a prefix arg the meaning of
(t
(let ((articles 1)
group-opened)
+ ;; work arround IMAP servers that perform badly in
+ ;; SEARCH commands.
+ (when (and (eq backend 'nnimap)
+ org-gnus-nnimap-query-article-no-from-file)
+ (let ((headers (nnimap-retrieve-headers-from-file group server)))
+ (message "headers = %s" headers)))
(while (and (not group-opened)
;; stop on integer overflows
(> articles 0))
--8<---------------cut here---------------end--------------->8---
> and the headers are not fetched because
> `nnimap-retrieve-headers-from-file' looks for a NOV cache file, not
> .overview.
Aren't overview file and NOV file synonyms?
Hm, anyway. In the Gnus docs I've found this paragraph:
,----[ (info "(gnus)IMAP") ]
| `nnimap-nov-is-evil'
| Never generate or use a local NOV database. Defaults to the value
| of `gnus-agent'.
|
| Using a NOV database usually makes header fetching much faster,
| but it uses the `UID SEARCH UID' command, which is very slow on
| some servers (notably some versions of Courier). Since the Gnus
| Agent caches the information in the NOV database without using the
| slow command, this variable defaults to true if the Agent is in
| use, and false otherwise.
`----
So maybe we're trying to replace one slow command with another slow
command. Especially, the fact that Courier is explicitly mentioned is a
bit frustrating. Well, let's try it out and see if it helps a bit.
> Alas: I couldn't figure out how to enable NOV cache for my nnimap
> group. Setting `nnimap-nov-is-evil' to nil didn't help.
This variable defaults to the value of `gnus-agent', so I assume the
agent has to be enabled (which is default), and most probably the IMAP
server has to be agentized as well. That can be done in the server
buffer (`^' in *Group*), and then:
,----[ (info "(gnus)Server Agent Commands") ]
| `J a'
| Add the current server to the list of servers covered by the Gnus
| Agent (`gnus-agent-add-server').
`----
Bye,
Tassilo
^ permalink raw reply related [flat|nested] 77+ messages in thread
* Re: Fixing slowness of following Gnus links to IMAP articles
2010-07-27 6:45 ` Fixing slowness of following Gnus links to IMAP articles (was: Behavior of Gnus when called from an hyperlink) Tassilo Horn
2010-07-27 20:27 ` David Maus
@ 2010-08-03 8:01 ` Sébastien Vauban
2010-08-05 18:21 ` Tassilo Horn
1 sibling, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-08-03 8:01 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo and David,
Tassilo Horn wrote:
> I'm trying to add a workaround to org-gnus.el which should save the slowness
> of querying the IMAP server by looking up the article number in the group's
> .overview file. But since I don't have nnimap groups, we have to play some
> question & answer game. ;-)
Just to give you feedback, here's a cite from the answer of my postmaster
about the bad experiences with Courier:
"Had a search and it appears that courier doesn't support this. The best
solution would be to upgrade our mail server to use dovecot."
Seems it must be fixed, then, by either of the following approaches:
- enhance Gnus's cache (what you tried)
- move client from Gnus to Wanderlust (but I'm not yet convinced about such a
move)
- move server from Courier to Dovecot (depends on my postmaster)
Thanks to you...
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Fixing slowness of following Gnus links to IMAP articles
2010-08-03 8:01 ` Fixing slowness of following Gnus links to IMAP articles Sébastien Vauban
@ 2010-08-05 18:21 ` Tassilo Horn
0 siblings, 0 replies; 77+ messages in thread
From: Tassilo Horn @ 2010-08-05 18:21 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
Hi Sébastien,
> Just to give you feedback, here's a cite from the answer of my
> postmaster about the bad experiences with Courier:
>
> "Had a search and it appears that courier doesn't support this. The
> best solution would be to upgrade our mail server to use dovecot."
He is definitively right, and should go the way of the best solution.
For now, I didn't have time to work any further on that workaround, and
on Saturday I'll go on an offline holiday. So don't hold your breath
for having that worked around quickly. (On the sly, I hope that this
workaround won't be needed anymore when I come back. ;-))
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-19 20:37 ` Sébastien Vauban
2010-07-20 6:23 ` David Maus
@ 2010-07-20 11:50 ` Tassilo Horn
2010-07-21 19:28 ` Sébastien Vauban
2010-07-20 12:08 ` Bernt Hansen
2 siblings, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-20 11:50 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
Hi Sébastien,
>> My main account uses Courier on Debian, too and search for a
>> particular message id within ~7000 messages is quite fast.
>
> In my case, the culprit seems well to be our mail server, then.
Yes, but not you've learned much about profiling and debugging
elisp. ;-)
> What would be your pieces of advice in such a case? Do I need to test
> something extra? Get a local imap server? Others (like asking for
> fixing the search on our Courier mail server)?
I'd definitively drop a mail to the admins. Searching for a message-id
is quite a common task, so that should be as fast as possible. And I'm
pretty sure Courier has some option to index at least the message-ids.
I used at least Dovecot and Cyrus IMAP servers, and both support such a
feature. I'd really wonder if Courier didn't support that.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-20 11:50 ` Behavior of Gnus when called from an hyperlink Tassilo Horn
@ 2010-07-21 19:28 ` Sébastien Vauban
0 siblings, 0 replies; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-21 19:28 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>
>>> My main account uses Courier on Debian, too and search for a particular
>>> message id within ~7000 messages is quite fast.
>>
>> In my case, the culprit seems well to be our mail server, then.
>
> Yes, but not you've learned much about profiling and debugging elisp. ;-)
Oh yes. And that is really unvaluable. I can dream beginning to write my own
ELisp code, now, being able to trace and easily follow what my code would do,
without having to write (message "...") calls (with the problem that I could
not display every object value.
Thanks a lot to you all for that.
>> What would be your pieces of advice in such a case? Do I need to test
>> something extra? Get a local imap server? Others (like asking for fixing
>> the search on our Courier mail server)?
>
> I'd definitively drop a mail to the admins. Searching for a message-id is
> quite a common task, so that should be as fast as possible. And I'm pretty
> sure Courier has some option to index at least the message-ids.
I'll do.
Thanks a lot for your help...
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-19 20:37 ` Sébastien Vauban
2010-07-20 6:23 ` David Maus
2010-07-20 11:50 ` Behavior of Gnus when called from an hyperlink Tassilo Horn
@ 2010-07-20 12:08 ` Bernt Hansen
2010-07-20 16:11 ` Tassilo Horn
2010-07-21 19:33 ` Sébastien Vauban
2 siblings, 2 replies; 77+ messages in thread
From: Bernt Hansen @ 2010-07-20 12:08 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
writes:
> Hi David, Tassilo and Nick,
>
> David Maus wrote:
>> Tassilo Horn wrote:
> [sva@mundaneum] />nc -vv mail imap
> Did twice the same request. Did take twice 5 mins...
> In my case, the culprit seems well to be our mail server, then.
>
>> Couldn't find this information in the tread: Is it slow for a particular
>> message or slow on Inbox.work in general?
>
> I answered this in the early beginning of the thread: time taken for opening
> the link seems to be (linearly?) dependant on the size of the mail groups.
>
> In INBOX.mc (the group for all work-related emails, containing ~27,000
> emails), it takes ~5 mins to open a link from Org.
>
> In other normally-sized groups (a couple of 100's of emails), it took a couple
> of seconds (> 10 s).
>
> Maybe a problem is that I keep all of my emails (but the spams...) since the
> beginning: now, over 140,000 emails entered my INBOX -- only the spams left
> it.
>
> What would be your pieces of advice in such a case? Do I need to test
> something extra? Get a local imap server? Others (like asking for fixing the
> search on our Courier mail server)?
>
> Best regards,
> Seb
Hi Sébastien,
I have an IMAP server on my local 100MB/sec network and one of my (spam)
folders has 148200 messages in it. If I link to one of those messages
in Gnus, close Gnus, and access the link from org-mode it finds the
email in 13 seconds (8 seconds if Gnus is already open which is how I
normally leave it running)
If you are accessing your mail server on a slower network then that will
adversely affect your response times.
Mirroring your mail server with offline imap or some other tool and
linking to the local mirror might help your access times. I've never
used that myself but others have reported success with this.
I also keep all of my emails except for SPAM which I clear out
periodically (it seems I'm due for that again ;)
Regards,
Bernt
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-20 12:08 ` Bernt Hansen
@ 2010-07-20 16:11 ` Tassilo Horn
2010-07-21 19:38 ` Sébastien Vauban
2010-07-21 19:33 ` Sébastien Vauban
1 sibling, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-20 16:11 UTC (permalink / raw)
To: emacs-orgmode
Bernt Hansen <bernt@norang.ca> writes:
Hi Bernt,
> I have an IMAP server on my local 100MB/sec network and one of my
> (spam) folders has 148200 messages in it. If I link to one of those
> messages in Gnus, close Gnus, and access the link from org-mode it
> finds the email in 13 seconds (8 seconds if Gnus is already open which
> is how I normally leave it running)
>
> If you are accessing your mail server on a slower network then that
> will adversely affect your response times.
No, that shouldn't affect the total time that much, at least in this
case. It's only one request and one reply that go over the net. The 5
minutes searching are what really matters, and that's only on the
server.
> Mirroring your mail server with offline imap or some other tool and
> linking to the local mirror might help your access times.
If Sébastien's admins tell him that they cannot get the search faster,
that would be a good investment. I recommend Dovecot as server and
OfflineIMAP for synchronizing the local with possibly many remote
accounts/servers. Dovecot has plugins even to do index every mail
completely, and then you can use Gnus' nnir backend to perform searches
for arbitrary text in the mails (including text in the bodies) in nearly
instant time.
But of course, that adds another layer of indirection requiring some
configs. IMO, when you often rename/create/delete IMAP folders,
OfflineIMAP doesn't do to well, at least in my limited experiences.
It's designed to never ever loose mail (which is surely most important),
but when deleting folders on the local Dovecot using Gnus, the deletion
never propagated to the remote server and the next synchronization
fetched the deleted folder again from the remote side...
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-20 16:11 ` Tassilo Horn
@ 2010-07-21 19:38 ` Sébastien Vauban
2010-07-22 12:29 ` Tassilo Horn
0 siblings, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-21 19:38 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo,
Tassilo Horn wrote:
> Bernt Hansen <bernt-CNteSEi18yz3fQ9qLvQP4Q@public.gmane.org> writes:
>> Mirroring your mail server with offline imap or some other tool and linking
>> to the local mirror might help your access times.
>
> If Sébastien's admins tell him that they cannot get the search faster, that
> would be a good investment. I recommend Dovecot as server and OfflineIMAP
> for synchronizing the local with possibly many remote accounts/servers.
> Dovecot has plugins even to do index every mail completely, and then you can
> use Gnus' nnir backend to perform searches for arbitrary text in the mails
> (including text in the bodies) in nearly instant time.
>
> But of course, that adds another layer of indirection requiring some
> configs. IMO, when you often rename/create/delete IMAP folders, OfflineIMAP
> doesn't do to well, at least in my limited experiences. It's designed to
> never ever loose mail (which is surely most important), but when deleting
> folders on the local Dovecot using Gnus, the deletion never propagated to
> the remote server and the next synchronization fetched the deleted folder
> again from the remote side...
I'll drop an email to my admin.
Even if feasable, doing your way seems to add a layer of complexity to the
installation... Would you have config to share, would I go that way?
Thanks a lot, anyway, for your precious advice.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-21 19:38 ` Sébastien Vauban
@ 2010-07-22 12:29 ` Tassilo Horn
2010-07-22 13:51 ` Matt Lundin
2010-07-22 19:21 ` Sébastien Vauban
0 siblings, 2 replies; 77+ messages in thread
From: Tassilo Horn @ 2010-07-22 12:29 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
> Even if feasable, doing your way seems to add a layer of complexity to
> the installation... Would you have config to share, would I go that
> way?
Sure, but be aware that I don't use that setup anymore.
Here's my .offlineimaprc. It synched from 2 different accounts from two
different imap servers to one locally running dovecot server with 2
user accounts uni and fastmail. Those are only plain dovecot users,
they don't require system users.
--8<---------------cut here---------------start------------->8---
[general]
accounts = Fastmail, Uni
ui = Noninteractive.Basic
maxsyncaccounts = 2
[Account Fastmail]
localrepository = FastmailLocal
remoterepository = FastmailRemote
[Repository FastmailLocal]
type = IMAP
ssl = no
remotehost = localhost
remoteuser = fastmail
remotepass = topsecret123
maxconnections = 1
[Repository FastmailRemote]
type = IMAP
ssl =yes
remotehost = mail.messagingengine.com
remoteuser = XXXXX
remotepass = XXXXX
maxconnections = 1
[Account Uni]
localrepository = UniLocal
remoterepository = UniRemote
[Repository UniLocal]
type = IMAP
ssl = no
remotehost = localhost
remoteuser = uni
remotepass = 321topsecret
maxconnections = 1
[Repository UniRemote]
type = IMAP
ssl =yes
remotehost = mail.uni-koblenz.de
remoteuser = XXXX
remotepass = XXXX
maxconnections = 1
# Don't sync shared folders
folderfilter = lambda foldername: not re.search('(Other Users|Shared Folders)', foldername)
--8<---------------cut here---------------end--------------->8---
Here's the /etc/dovecot/passwd defining the 2 dovecot users.
--8<---------------cut here---------------start------------->8---
fastmail:{PLAIN}topsecret123
uni:{PLAIN}321topsecret
--8<---------------cut here---------------end--------------->8---
And here's the Dovecot config (/etc/dovecot/dovecot.conf). The config
option for the full text index is somehow lost, but you will find it on
dovecot's wiki. It's a one-liner.
--8<---------------cut here---------------start------------->8---
log_path = /var/log/dovecot.log
ssl_cert_file = /etc/ssl/dovecot/server.pem
ssl_key_file = /etc/ssl/dovecot/server.key
mail_location = dbox:/var/spool/mail/%u
mail_process_size = 1024
protocol imap {
listen = 127.0.0.1:143
ssl_listen = 127.0.0.1:943
}
first_valid_uid = 1
auth default {
mechanisms = plain
passdb passwd-file {
# File contains a list of usernames, one per line
args = /etc/dovecot/passwd
}
userdb static {
args = uid=mail gid=mail home=/var/spool/mail/%u
}
}
--8<---------------cut here---------------end--------------->8---
HTH,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-07-22 12:29 ` Tassilo Horn
@ 2010-07-22 13:51 ` Matt Lundin
2010-07-22 19:29 ` Sébastien Vauban
2010-07-22 19:21 ` Sébastien Vauban
1 sibling, 1 reply; 77+ messages in thread
From: Matt Lundin @ 2010-07-22 13:51 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-orgmode
Tassilo Horn <tassilo@member.fsf.org> writes:
> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
> writes:
>
>> Even if feasable, doing your way seems to add a layer of complexity to
>> the installation... Would you have config to share, would I go that
>> way?
>
> Sure, but be aware that I don't use that setup anymore.
>
> Here's my .offlineimaprc. It synched from 2 different accounts from two
> different imap servers to one locally running dovecot server with 2
> user accounts uni and fastmail. Those are only plain dovecot users,
> they don't require system users.
Not to take this thread too far from the well-beaten org-mode path, but
I'd like to add that if you don't want to run dovecot as a daemon, you
can invoke it as a process from both gnus and offlineimap. This
simplifies setting up the dovecot.conf file considerably.
Here are the relevant lines from my .offlineimaprc:
--8<---------------cut here---------------start------------->8---
[Repository Local]
type = IMAP
preauthtunnel = /usr/sbin/dovecot -c ~/config/mail/dovecot.conf --exec-mail imap
--8<---------------cut here---------------end--------------->8---
...and my .gnus:
--8<---------------cut here---------------start------------->8---
(setq imap-shell-program "dovecot -c ~/config/mail/dovecot.conf --exec-mail imap")
(setq gnus-secondary-select-methods
'(
(nnimap "fm"
(nnimap-stream shell))
;; [snip] more methods here
))
--8<---------------cut here---------------end--------------->8---
Best,
Matt
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Behavior of Gnus when called from an hyperlink
2010-07-22 13:51 ` Matt Lundin
@ 2010-07-22 19:29 ` Sébastien Vauban
0 siblings, 0 replies; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-22 19:29 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Matt,
Matt Lundin wrote:
> Tassilo Horn <tassilo-IGUgQLVVQiRCV4ILt04nZQ@public.gmane.org> writes:
>> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>
>>> Even if feasable, doing your way seems to add a layer of complexity to the
>>> installation... Would you have config to share, would I go that way?
>>
>> Here's my .offlineimaprc. It synched from 2 different accounts from two
>> different imap servers to one locally running dovecot server with 2
>> user accounts uni and fastmail. Those are only plain dovecot users,
>> they don't require system users.
>
> I'd like to add that if you don't want to run dovecot as a daemon, you
> can invoke it as a process from both gnus and offlineimap. This
> simplifies setting up the dovecot.conf file considerably.
Always good to know. Thanks for the followup.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-22 12:29 ` Tassilo Horn
2010-07-22 13:51 ` Matt Lundin
@ 2010-07-22 19:21 ` Sébastien Vauban
2010-07-22 20:11 ` Tassilo Horn
1 sibling, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-22 19:21 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>
>> Even if feasable, doing your way seems to add a layer of complexity to the
>> installation... Would you have config to share, would I go that way?
>
> Sure, but be aware that I don't use that setup anymore.
Thanks a lot for the detailed information you provided us with... But may I
ask what's your current setup, then (did I miss that information in your
previous posts?)...
And why did you stop using it?
Once again, thanks a lot for the precious help you give me/us.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-22 19:21 ` Sébastien Vauban
@ 2010-07-22 20:11 ` Tassilo Horn
2010-07-23 8:54 ` Giovanni Ridolfi
0 siblings, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-22 20:11 UTC (permalink / raw)
To: emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com>
writes:
Hi Sébastien,
>>> Even if feasable, doing your way seems to add a layer of complexity
>>> to the installation... Would you have config to share, would I go
>>> that way?
>>
>> Sure, but be aware that I don't use that setup anymore.
>
> Thanks a lot for the detailed information you provided us with... But
> may I ask what's your current setup, then (did I miss that information
> in your previous posts?)...
Sure. Now I use Gnus only for newsgroups and KMail (with emacs(client)
as editor and a custom message-mode derived mode) for mails.
For the completeness, here's the mode:
--8<---------------cut here---------------start------------->8---
(defvar th-kmail-tmp-file-regexp "\\(kontact\\|kmail\\).*\\.tmp$"
"Regexp that matches the file names of kmail's temporary files.")
(defun kmail-save-message-and-exit ()
(interactive)
(goto-char 0)
(forward-line 1)
(delete-region 1 (point))
(save-buffer)
(server-edit))
(define-derived-mode kmail-mode message-mode "KMail"
"Major mode for editing mails from kmail.
\\{kmail-mode-map}"
(goto-char 0)
(insert "--text follows this line--\n")
(define-key kmail-mode-map (kbd "C-c C-c") 'kmail-save-message-and-exit)
(define-key kmail-mode-map (kbd "C-c #") 'kmail-save-message-and-exit))
(add-hook 'kmail-mode-hook 'th-message-mode-init)
(add-to-list 'auto-mode-alist
(cons th-kmail-tmp-file-regexp 'kmail-mode))
(add-to-list 'recentf-exclude th-kmail-tmp-file-regexp)
--8<---------------cut here---------------end--------------->8---
> And why did you stop using it?
I gave up on my offlineimap/dovecot/gnus combo (I used happily many
years) because I frequently subscribe to mailinglists for only a short
period of time, and this didn't work out too well with offlineimap.
And I like being able to restrict the message list incrementally by
simply entering parts of the author name or subject. Gnus cannot do
that. But I think there's a anything-source for that right now, but for
me it came a bit too late.
> Once again, thanks a lot for the precious help you give me/us.
I'm happy for being useful. :-)
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread* Re: Re: Behavior of Gnus when called from an hyperlink
2010-07-22 20:11 ` Tassilo Horn
@ 2010-07-23 8:54 ` Giovanni Ridolfi
2010-07-23 10:40 ` Tassilo Horn
0 siblings, 1 reply; 77+ messages in thread
From: Giovanni Ridolfi @ 2010-07-23 8:54 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-orgmode
Tassilo Horn <tassilo@member.fsf.org> writes:
> And I like being able to restrict the message list incrementally by
> simply entering parts of the author name or subject. Gnus cannot do
> that.
may be ths can help:
1. cursor in the "Summary message" buffer
# let's restrict to headers:
2. / h $the-header-you-like # I'd use "23 Jul" to read only the messages of today
cheers,
Giovanni
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Re: Behavior of Gnus when called from an hyperlink
2010-07-23 8:54 ` Giovanni Ridolfi
@ 2010-07-23 10:40 ` Tassilo Horn
2010-07-24 22:32 ` Sébastien Vauban
0 siblings, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-23 10:40 UTC (permalink / raw)
To: Giovanni Ridolfi; +Cc: emacs-orgmode
On Friday 23 July 2010 10:54:24 Giovanni Ridolfi wrote:
> > And I like being able to restrict the message list incrementally by
> > simply entering parts of the author name or subject. Gnus cannot do
> > that.
> may be ths can help:
>
> 1. cursor in the "Summary message" buffer
>
> # let's restrict to headers:
>
> 2. / h $the-header-you-like # I'd use "23 Jul" to read only the messages of today
Yes, the various restrictions basically do what I want, except that they
don't work incrementally while typing and first you have to start with a
summary containing many/all messages, which takes some time to create.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-23 10:40 ` Tassilo Horn
@ 2010-07-24 22:32 ` Sébastien Vauban
0 siblings, 0 replies; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-24 22:32 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Tassilo and Giovanni,
Tassilo Horn wrote:
> On Friday 23 July 2010 10:54:24 Giovanni Ridolfi wrote:
>>> And I like being able to restrict the message list incrementally by
>>> simply entering parts of the author name or subject. Gnus cannot do
>>> that.
>>
>> may be ths can help:
>>
>> 1. cursor in the "Summary message" buffer
>>
>> # let's restrict to headers:
>>
>> 2. / h $the-header-you-like # I'd use "23 Jul" to read only the messages of
>> today
>
> Yes, the various restrictions basically do what I want, except that they
> don't work incrementally while typing and first you have to start with a
> summary containing many/all messages, which takes some time to create.
Thanks for your precision about the local imap server, and this new filter I
did not know about (/h).
I share your point of view, Tassilo, about the (absence of) incremental
filtering.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-20 12:08 ` Bernt Hansen
2010-07-20 16:11 ` Tassilo Horn
@ 2010-07-21 19:33 ` Sébastien Vauban
2010-07-21 23:30 ` Bernt Hansen
1 sibling, 1 reply; 77+ messages in thread
From: Sébastien Vauban @ 2010-07-21 19:33 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Bernt,
Bernt Hansen wrote:
> Sébastien Vauban writes:
>> David Maus wrote:
>>> Tassilo Horn wrote:
>> [sva@mundaneum] />nc -vv mail imap
>>
>> Did twice the same request. Did take twice 5 mins...
>>
>> In my case, the culprit seems well to be our mail server, then.
>>
>> Maybe a problem is that I keep all of my emails (but the spams...) since the
>> beginning: now, over 140,000 emails entered my INBOX -- only the spams left
>> it.
>>
>> What would be your pieces of advice in such a case? Do I need to test
>> something extra? Get a local imap server? Others (like asking for fixing the
>> search on our Courier mail server)?
>
> I have an IMAP server on my local 100MB/sec network and one of my (spam)
> folders has 148200 messages in it. If I link to one of those messages in
> Gnus, close Gnus, and access the link from org-mode it finds the email in 13
> seconds (8 seconds if Gnus is already open which is how I normally leave it
> running)
>
> If you are accessing your mail server on a slower network then that will
> adversely affect your response times.
I'm using a 100 Mbps network as well. That does not seem to be the problem,
and as stated by Tassilo, only one request is made...
> Mirroring your mail server with offline imap or some other tool and linking
> to the local mirror might help your access times. I've never used that
> myself but others have reported success with this.
I am (or was) a bit reluctant about this, as I always try (or tried) to have
portable solutions that my colleagues can use on Windows. Some of them use my
.emacs file, just changing user-name variables and some such. Same for my
.gnus file.
Installing local imap servers only running on Ubuntu is thus inserting a
difference that others won't be able to match. But if that's the way to go.
Bernt, what's your IMAP server, by the way?
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Behavior of Gnus when called from an hyperlink
2010-07-21 19:33 ` Sébastien Vauban
@ 2010-07-21 23:30 ` Bernt Hansen
0 siblings, 0 replies; 77+ messages in thread
From: Bernt Hansen @ 2010-07-21 23:30 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
writes:
> Hi Bernt,
>
> Bernt Hansen wrote:
>> Mirroring your mail server with offline imap or some other tool and linking
>> to the local mirror might help your access times. I've never used that
>> myself but others have reported success with this.
>
> I am (or was) a bit reluctant about this, as I always try (or tried) to have
> portable solutions that my colleagues can use on Windows. Some of them use my
> .emacs file, just changing user-name variables and some such. Same for my
> .gnus file.
>
> Installing local imap servers only running on Ubuntu is thus inserting a
> difference that others won't be able to match. But if that's the way to go.
>
> Bernt, what's your IMAP server, by the way?
I use Cyrus on my network.
-Bernt
^ permalink raw reply [flat|nested] 77+ messages in thread
end of thread, other threads:[~2010-10-11 18:34 UTC | newest]
Thread overview: 77+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-28 9:38 Behavior of Gnus when called from an hyperlink Sébastien Vauban
2010-06-28 10:19 ` Tassilo Horn
2010-06-28 11:36 ` Leo
2010-06-28 11:49 ` Carsten Dominik
2010-06-28 12:47 ` Bernt Hansen
2010-06-28 13:57 ` Greg Troxel
2010-06-28 19:44 ` [PATCH] Add customization for WL in `org-link-frame-setup' David Maus
2010-06-29 4:42 ` Carsten Dominik
2010-06-28 19:44 ` [PATCH] Add customization option to open WL links in other frame David Maus
2010-06-30 10:12 ` Behavior of Gnus when called from an hyperlink Noorul Islam K M
2010-07-02 4:44 ` Carsten Dominik
2010-07-02 8:21 ` Leo
2010-07-02 8:21 ` Bastien
2010-07-02 11:59 ` Bernt Hansen
2010-06-28 12:05 ` Sébastien Vauban
2010-06-28 12:51 ` Sébastien Vauban
2010-06-28 14:39 ` Nick Dokos
2010-06-28 14:51 ` Sébastien Vauban
2010-06-28 15:19 ` Nick Dokos
2010-06-28 18:32 ` Tassilo Horn
2010-07-15 21:27 ` Sébastien Vauban
2010-07-16 7:50 ` Tassilo Horn
2010-07-16 11:39 ` Sébastien Vauban
2010-07-16 18:11 ` Nick Dokos
2010-07-16 19:23 ` Sébastien Vauban
2010-07-16 19:51 ` Sébastien Vauban
2010-07-17 7:18 ` Tassilo Horn
2010-07-17 16:02 ` Nick Dokos
2010-07-17 19:59 ` Sébastien Vauban
2010-07-17 20:49 ` Nick Dokos
2010-07-17 21:34 ` Sébastien Vauban
2010-07-17 22:15 ` Sébastien Vauban
2010-07-19 8:11 ` Tassilo Horn
2010-07-19 12:02 ` David Maus
2010-07-19 20:37 ` Sébastien Vauban
2010-07-20 6:23 ` David Maus
2010-07-21 19:59 ` Sébastien Vauban
2010-07-22 12:31 ` Tassilo Horn
2010-07-26 13:17 ` David Maus
2010-07-26 15:12 ` Tassilo Horn
2010-07-26 18:47 ` Tassilo Horn
2010-07-27 6:45 ` Fixing slowness of following Gnus links to IMAP articles (was: Behavior of Gnus when called from an hyperlink) Tassilo Horn
2010-07-27 20:27 ` David Maus
2010-07-27 21:18 ` Nick Dokos
2010-07-28 6:50 ` Fixing slowness of following Gnus links to IMAP articles Tassilo Horn
2010-07-29 7:33 ` David Maus
2010-07-29 18:06 ` Tassilo Horn
2010-07-30 20:03 ` Sébastien Vauban
2010-08-15 18:52 ` David Maus
2010-09-08 15:09 ` Sébastien Vauban
2010-09-08 19:08 ` David Maus
2010-09-08 21:42 ` Sébastien Vauban
2010-09-09 12:19 ` David Maus
2010-10-01 0:53 ` Matt Lundin
2010-10-11 18:33 ` David Maus
2010-08-01 8:38 ` David Maus
2010-07-28 6:36 ` Tassilo Horn
2010-07-31 8:34 ` Patchwork: Patch 176 Accepted Bastien Guerry
2010-07-31 18:21 ` Tassilo Horn
2010-07-31 23:52 ` Bastien
2010-08-03 8:01 ` Fixing slowness of following Gnus links to IMAP articles Sébastien Vauban
2010-08-05 18:21 ` Tassilo Horn
2010-07-20 11:50 ` Behavior of Gnus when called from an hyperlink Tassilo Horn
2010-07-21 19:28 ` Sébastien Vauban
2010-07-20 12:08 ` Bernt Hansen
2010-07-20 16:11 ` Tassilo Horn
2010-07-21 19:38 ` Sébastien Vauban
2010-07-22 12:29 ` Tassilo Horn
2010-07-22 13:51 ` Matt Lundin
2010-07-22 19:29 ` Sébastien Vauban
2010-07-22 19:21 ` Sébastien Vauban
2010-07-22 20:11 ` Tassilo Horn
2010-07-23 8:54 ` Giovanni Ridolfi
2010-07-23 10:40 ` Tassilo Horn
2010-07-24 22:32 ` Sébastien Vauban
2010-07-21 19:33 ` Sébastien Vauban
2010-07-21 23:30 ` Bernt Hansen
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).