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
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
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.
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
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
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
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
[-- 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
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
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
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
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
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(-)
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
=?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
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
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
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
[-- 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
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
[-- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[-- 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
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
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
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
[-- 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
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
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
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
[-- 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
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
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
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
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
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
[-- 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
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
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
[-- 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
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
[-- 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
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
[-- 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
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
[-- 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