[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Tassilo Horn 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 d...@gnus.org, or should I do this > evening? Ok, I reported the issue on the ding list. Message-Id: <201007262042.04971.tass...@member.fsf.org> Gmane: http://article.gmane.org/gmane.emacs.gnus.general/69829 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: Behavior of Gnus when called from an hyperlink
David Maus 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/// 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 d...@gnus.org, or should I do this
evening?
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
Re: [Orgmode] Re: Behavior of Gnus when called from an hyperlink
Tassilo Horn wrote:
>Sébastien Vauban
>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/// 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 dmj...@jabber.org
Email. dm...@ictsoc.de
pgp0i9hW9pqgz.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: Behavior of Gnus when called from an hyperlink
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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Behavior of Gnus when called from an hyperlink
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 ___ 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: Behavior of Gnus when called from an hyperlink
Tassilo Horn 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 ___ 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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban
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
___
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: Behavior of Gnus when called from an hyperlink
Hi Matt, Matt Lundin wrote: > Tassilo Horn writes: >> Sébastien Vauban 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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Hi Tassilo, Tassilo Horn wrote: > Sébastien Vauban 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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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 ___ 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: Behavior of Gnus when called from an hyperlink
Tassilo Horn writes: > Sébastien Vauban > 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 ___ 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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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 ___ 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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban
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 = X
remotepass = X
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 =
remotepass =
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
___
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: Behavior of Gnus when called from an hyperlink
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@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. Your guess is right: --8<---cut here---start->8--- [...@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" "" 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@mundaneum.com" * 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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Hi Tassilo, Tassilo Horn wrote: > Bernt Hansen 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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Hi Tassilo, Tassilo Horn wrote: > Sébastien Vauban 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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Hi Bernt, Bernt Hansen wrote: > Sébastien Vauban writes: >> David Maus wrote: >>> Tassilo Horn wrote: >> [...@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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Bernt Hansen 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 ___ 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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban writes: > Hi David, Tassilo and Nick, > > David Maus wrote: >> Tassilo Horn wrote: > [...@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 ___ 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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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 ___ 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: Behavior of Gnus when called from an hyperlink
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@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 dmj...@jabber.org Email. dm...@ictsoc.de pgpMZ7zMuBJCV.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: Behavior of Gnus when called from an hyperlink
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--- [...@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" "" 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@mundaneum.com" * SEARCH 26856 0x3 OK SEARCH done. 0x3 SEARCH HEADER "Message-ID" "871vbrxzo6@mundaneum.com" * SEARCH 26856 0x3 OK SEARCH done. 0x4 LOGOUT * BYE Courier-IMAP server shutting down 0x4 OK LOGOUT completed [...@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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Behavior of Gnus when called from an hyperlink
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 dmj...@jabber.org Email. dm...@ictsoc.de pgp1fUJvlUMHd.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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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@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 ___ 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: Behavior of Gnus when called from an hyperlink
Nick, Tassilo,
> Nick Dokos wrote:
>> =?utf-8?Q?S=C3=A9bastien_Vauban?= wrote:
>>
>>> - (funcall nnimap-request-head
>>> "<871vbxzo6@mundaneum.com>" "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.16610285.388700
> nnimap-request-article-part 3 256.16600485.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@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.
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@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Hi Nick,
Nick Dokos wrote:
> =?utf-8?Q?S=C3=A9bastien_Vauban?= wrote:
>
>> - (funcall nnimap-request-head "<871vbxzo6@mundaneum.com>" "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.16610285.388700666
nnimap-request-article-part 3 256.16600485.388668
nnimap-request-group 2 12.306432000 6.153216
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@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Behavior of Gnus when called from an hyperlink
=?utf-8?Q?S=C3=A9bastien_Vauban?= 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@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@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
___
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: Behavior of Gnus when called from an hyperlink
Hi Nick and Tassilo,
Nick Dokos wrote:
> Tassilo Horn wrote:
>> Sébastien Vauban 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@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@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?
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@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Behavior of Gnus when called from an hyperlink
Tassilo Horn wrote: > Sébastien Vauban > 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 ___ 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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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 ___ 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: Behavior of Gnus when called from an hyperlink
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.993525312.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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Hi Nick, Nick Dokos wrote: > Sébastien Vauban wrote: >> 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.993525312.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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Behavior of Gnus when called from an hyperlink
Sébastien Vauban wrote: > 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.993525312.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 ___ 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: Behavior of Gnus when called from an hyperlink
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.993525312.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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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.993525312.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 ___ 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: Behavior of Gnus when called from an hyperlink
Hi Tassilo, Tassilo Horn wrote: > Sébastien Vauban 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-return1 336.683827336.683827 org-open-at-point 1 336.683692336.683692 org-gnus-open 1 336.681615336.681615 org-gnus-follow-link 1 336.681557336.681557 gnus-summary-goto-article 1 315.14423 315.14423 gnus-summary-refer-article1 315.144193315.144193 gnus-summary-insert-subject 1 313.003412313.003412 gnus-read-header 1 312.994378312.994378 gnus-request-head 1 312.993525312.993525 gnus-activate-group 1 13.587475 13.587475 gnus-group-read-group 1 7.949638 7.949638 gnus-summary-read-group 1 7.94967.9496 gnus-summary-read-group-1 1 7.949586 7.949586 gnus-select-newsgroup 1 7.851293 7.851293 gnus-request-group1 6.671263 6.671263 gnus-server-opened4 3.312642 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.906248 0.953124 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-metaup4 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-region3 0.364508 0.121502 org-agenda-save-markers-for-cut-and-paste 3 0.364005 0.121335 org-check-and-save-marker 714 0.358820 0.0005025504 org-shifttab 8 0.156744 0.019593 org-global-cycle 8 0.15602 0.0195025 org-cycle 8 0.155811 0.0194764999 org-cycle-internal-global 8 0.148777 0.018597125 gnus-run-hooks 22 0.133493 0.0060679090 gnus-summary-mark-read-and-unread-as-read 1 0.124569 0.124569 gnus-summary-mark-article 1 0.124472 0.124472 g
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Carsten Dominik writes: > do we have an agreement that the default frame setup for gnus should > be org-gnus-no-new-news? Yes. -Bernt ___ 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: Behavior of Gnus when called from an hyperlink
Carsten Dominik writes: > do we have an agreement that the default frame setup for gnus should be > org-gnus-no-new-news? +1 (FWIW) -- Bastien ___ 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: Behavior of Gnus when called from an hyperlink
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 ___ 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: Behavior of Gnus when called from an hyperlink
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 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 ___ 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: Behavior of Gnus when called from an hyperlink
Carsten Dominik 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 ___ 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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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 ___ 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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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 gnus There is a sharper scalpel too: M-x elp=instrument-function some-func Cheers, Nick ___ 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: Behavior of Gnus when called from an hyperlink
Hi Nick, Nick Dokos wrote: > Sébastien Vauban 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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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 ___ 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: Behavior of Gnus when called from an hyperlink
Carsten Dominik 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. pgppAxYI4d8Iy.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: Behavior of Gnus when called from an hyperlink
Hi Tassilo, Sébastien Vauban wrote: > Tassilo Horn wrote: >> Sébastien Vauban >> 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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Behavior of Gnus when called from an hyperlink
Carsten Dominik 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 ___ 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: Behavior of Gnus when called from an hyperlink
Hi Tassilo, Tassilo Horn wrote: > Sébastien Vauban 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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Behavior of Gnus when called from an hyperlink
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 ___ 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: Behavior of Gnus when called from an hyperlink
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. ___ 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: Behavior of Gnus when called from an hyperlink
Sébastien Vauban 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 ___ 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
