emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* 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 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 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: 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 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

* 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

* [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: [PATCH] Add customization for WL in `org-link-frame-setup'
  2010-06-28 19:44       ` [PATCH] Add customization for WL in `org-link-frame-setup' David Maus
@ 2010-06-29  4:42         ` Carsten Dominik
  0 siblings, 0 replies; 77+ messages in thread
From: Carsten Dominik @ 2010-06-29  4:42 UTC (permalink / raw)
  To: David Maus; +Cc: emacs-orgmode

Applied, thanks.

- Carsten

On Jun 28, 2010, at 9:44 PM, David Maus wrote:

> 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(-)
>
>
> _______________________________________________
> 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
                         ` (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-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
  2 siblings, 0 replies; 77+ messages in thread
From: Leo @ 2010-07-02  8:21 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: emacs-orgmode

On 2010-07-02 05:44 +0100, Carsten Dominik wrote:
> Hi,
>
> do we have an agreement that the default frame setup for gnus should
> be org-gnus-no-new-news?
>
> - Carsten

I vote for it.

Leo

^ permalink raw reply	[flat|nested] 77+ messages in thread

* Re: Re: Behavior of Gnus when called from an hyperlink
  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
  2 siblings, 0 replies; 77+ messages in thread
From: Bastien @ 2010-07-02  8:21 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: emacs-orgmode, Leo

Carsten Dominik <carsten.dominik@gmail.com> writes:

> do we have an agreement that the default frame setup for gnus should be
> org-gnus-no-new-news?

+1 (FWIW)

-- 
 Bastien

^ permalink raw reply	[flat|nested] 77+ messages in thread

* Re: Behavior of Gnus when called from an hyperlink
  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
  2 siblings, 0 replies; 77+ messages in thread
From: Bernt Hansen @ 2010-07-02 11:59 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: emacs-orgmode, Leo

Carsten Dominik <carsten.dominik@gmail.com> writes:

> do we have an agreement that the default frame setup for gnus should
> be org-gnus-no-new-news?

Yes.

-Bernt

^ 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-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-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 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-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-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-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: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

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

* Re: Behavior of Gnus when called from an hyperlink
  2010-07-26 15:12                                               ` Tassilo Horn
@ 2010-07-26 18:47                                                 ` Tassilo Horn
  0 siblings, 0 replies; 77+ messages in thread
From: Tassilo Horn @ 2010-07-26 18:47 UTC (permalink / raw)
  To: emacs-orgmode

Tassilo Horn <tassilo@member.fsf.org> writes:

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

Ok, I reported the issue on the ding list.

  Message-Id: <201007262042.04971.tassilo@member.fsf.org>
  Gmane: http://article.gmane.org/gmane.emacs.gnus.general/69829

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

* Patchwork: Patch 176 Accepted
  2010-07-28  6:36                                               ` Tassilo Horn
@ 2010-07-31  8:34                                                 ` Bastien Guerry
  2010-07-31 18:21                                                   ` Tassilo Horn
  0 siblings, 1 reply; 77+ messages in thread
From: Bastien Guerry @ 2010-07-31  8:34 UTC (permalink / raw)
  To: emacs-orgmode

Patch 176 (http://patchwork.newartisans.com/patch/176/) is now Accepted.

This relates to the following submission:

http://mid.gmane.org/%3C87fwz4159y.fsf%40thinkpad.tsdh.de%3E

^ permalink raw reply	[flat|nested] 77+ messages in thread

* Re: Patchwork: Patch 176 Accepted
  2010-07-31  8:34                                                 ` Patchwork: Patch 176 Accepted Bastien Guerry
@ 2010-07-31 18:21                                                   ` Tassilo Horn
  2010-07-31 23:52                                                     ` Bastien
  0 siblings, 1 reply; 77+ messages in thread
From: Tassilo Horn @ 2010-07-31 18:21 UTC (permalink / raw)
  To: Bastien Guerry; +Cc: emacs-orgmode

On Saturday 31 July 2010 10:34:56 Bastien Guerry wrote:

Hi Bastien,

> Patch 176 (http://patchwork.newartisans.com/patch/176/) is now Accepted.
> 
> This relates to the following submission:
> 
> http://mid.gmane.org/%3C87fwz4159y.fsf%40thinkpad.tsdh.de%3E

Oh, I didn't notice that this patch was grabbed by patchwork.  It should
definitively NOT be applied.  It's only half-finished and it seems the
workaround I was trying to implement won't work anyway.

Bye,
Tassilo

^ permalink raw reply	[flat|nested] 77+ messages in thread

* Re: Patchwork: Patch 176 Accepted
  2010-07-31 18:21                                                   ` Tassilo Horn
@ 2010-07-31 23:52                                                     ` Bastien
  0 siblings, 0 replies; 77+ messages in thread
From: Bastien @ 2010-07-31 23:52 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: emacs-orgmode

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> writes:

>> Patch 176 (http://patchwork.newartisans.com/patch/176/) is now Accepted.
>> 
>> This relates to the following submission:
>> 
>> http://mid.gmane.org/%3C87fwz4159y.fsf%40thinkpad.tsdh.de%3E
>
> Oh, I didn't notice that this patch was grabbed by patchwork.  

Yes, every (correctly) attached patch is grabbed by patchwork.

I misread your email and thought the correctED patch was the 
correct one...  sorry for that.

I reverted the patch.

Thanks,

-- 
 Bastien

^ 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  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: 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

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).