[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
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 dmj...@jabber.org Email. dm...@ictsoc.de pgpTTn4vNpGYQ.pgp Description: PGP signature ___ 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
[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
Hi David, David Maus dm...@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 dm...@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 ___ 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
Re: [Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
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 dmj...@jabber.org Email. dm...@ictsoc.de pgpsHmsysdg2o.pgp Description: PGP signature ___ 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
[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
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-idle1 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-line1 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-string1 0.000262 0.000262 org-activate-bracket-links4 0.000246 6.15e-05 org-clock-get-clocked-time2 0.000221 0.0001105 org-activate-plain-links 4 0.000186 4.650...e-05 org-unfontify-region 2 0.00018 9e-05 org-float-time4 0.000176 4.4e-05 org-match-string-no-properties3 0.000123 4.1e-05 org-footnote-at-definition-p 1 0.000121 0.000121 org-link-unescape 1 0.000117 0.000117 org-propertize4 0.000115 2.875e-05 org-remove-flyspell-overlays-in 4 0.000104 2.6e-05 org-activate-tags 2 0.000100 5.049...e-05 org-substring-no-properties 4 9.7e-05 2.425e-05 org-before-change-function40 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-p1 6.1e-05 6.1e-05 org-link-expand-abbrev1 4.4e-05 4.4e-05 org-extract-attributes1 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
Re: [Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
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 dmj...@jabber.org Email. dm...@ictsoc.de pgpPCuKDrEbMk.pgp Description: PGP signature ___ 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
[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
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 dmj...@jabber.org Email. dm...@ictsoc.de 0001-Try-fix-1.patch Description: Binary data ___ 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
[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
Sébastien Vauban wxhgmqzgw...@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 ___ 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
[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
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 dmj...@jabber.org Email. dm...@ictsoc.de pgptd3ICl9sJa.pgp Description: PGP signature ___ 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
[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
Hi Tassilo and David, Tassilo Horn wrote: David Maus dm...@ictsoc.de 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.) , | dm...@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 | dm...@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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
Tassilo Horn wrote: Nick Dokos nicholas.do...@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 , | dm...@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 | dm...@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 yoi...@eken.phys.nagoya-u.ac.jp Sun, 13 Oct 2002 10:19:13 +0900 wyadljm8z2...@eken3.eken.phys.nagoya-u.ac.jp 87ptvqcd9p...@eken.phys.nagoya-u.ac.jp442413 Xref: t41.ictsoc.de INBOX:18753 Newsgroups: gmane.mail.wanderlust.general.japanese ` Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgp8bzQNu4ToA.pgp Description: PGP signature ___ 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
[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
David Maus dm...@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.) , | dm...@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 | dm...@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 yoi...@eken.phys.nagoya-u.ac.jp Sun, 13 Oct 2002 10:19:13 +0900 wyadljm8z2...@eken3.eken.phys.nagoya-u.ac.jp 87ptvqcd9p...@eken.phys.nagoya-u.ac.jp442413 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 ___ 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
[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
David Maus dm...@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 ___ 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
[Orgmode] Re: Fixing slowness of following Gnus links to IMAP articles
Nick Dokos nicholas.do...@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 ___ 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
