* Gnus is very slow in displaying headers. @ 2004-08-23 3:40 Daniel M. 2004-08-23 12:12 ` Jorge Godoy ` (3 more replies) 0 siblings, 4 replies; 19+ messages in thread From: Daniel M. @ 2004-08-23 3:40 UTC (permalink / raw) Hello everybody, I noticed that even when I enter a group with a relatively small amount of headers - in my case, 12000 for comp.lang.lisp, it takes Gnus a very long time to thread/load them (headers are already in the spool - they were downloaded previously by the Gnus) - 3 minutes and 100% CPU for the duration of that period. Forte Agent, for example, has no problem with groups which contain hundreds of thousands of headers - it takes merely a couple of seconds to load them, so it is not a lack of memory/CPU cycles. Am I doing something wrong, or is it a fundamental issue (elisp is too slow? something in the core of X/Emacs?) which renders Gnus unusable for anything more then a very small groups? After searching the group for a similar questions, I saw an advice to set nntp-marks-is-evil variable to 't', which I have done, but it made no noticable difference. I use Gnus 5.10.6 on Debian (precompiled package from unstable). BTW, listing of all active groups (zombie, killed groups - I am not sure how I am supposed to call them. In effect, it is the list of all groups carried by the server) also takes a lot of time - almost a full minute, although there are only ~32000 groups and the file containing them resides on the HD. I even tried to sort that file, but it didn't help :(. Daniel. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-23 3:40 Gnus is very slow in displaying headers Daniel M. @ 2004-08-23 12:12 ` Jorge Godoy 2004-08-24 6:02 ` Daniel M. 2004-08-24 4:49 ` Kevin Greiner ` (2 subsequent siblings) 3 siblings, 1 reply; 19+ messages in thread From: Jorge Godoy @ 2004-08-23 12:12 UTC (permalink / raw) Daniel M. <xt@nm.ru> writes: > I noticed that even when I enter a group with a relatively small > amount of headers - in my case, 12000 for comp.lang.lisp, it takes > Gnus a very long time to thread/load them (headers are already in > the spool - they were downloaded previously by the Gnus) - 3 minutes > and 100% CPU for the duration of that period. It doesn't happen here, but I have an nntp server (leafnode) on my LAN. Access here is almost instantaneous, except when I happen to get an article in HTML or some not-found-on-keyservers PGP key use to sign messages. > Am I doing something wrong, or is it a fundamental issue (elisp is too > slow? something in the core of X/Emacs?) which renders Gnus unusable > for anything more then a very small groups? I dunno what you're doing or how, but here the reality is different. It looks more like your Forte Agent. > BTW, listing of all active groups (zombie, killed groups - I am not > sure how I am supposed to call them. In effect, it is the list of all > groups carried by the server) also takes a lot of time - almost a full > minute, although there are only ~32000 groups and the file containing > them resides on the HD. I even tried to sort that file, but it didn't > help :(. Weird. It seems you're not using the local file, then... It is faster here and the amount of groups is also big (Usenet + a brazilian network with a few thousand groups). Have you tried removing your configuration and redoing it? Be seeing you, -- Godoy. <godoy@ieee.org> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-23 12:12 ` Jorge Godoy @ 2004-08-24 6:02 ` Daniel M. 2004-08-23 20:22 ` Jorge Godoy 0 siblings, 1 reply; 19+ messages in thread From: Daniel M. @ 2004-08-24 6:02 UTC (permalink / raw) > >It seems you're not using the local file, then... It is faster here and >the amount of groups is also big (Usenet + a brazilian network with a >few thousand groups). > >Have you tried removing your configuration and redoing it? Yes, I tried. Also, I tried to use Gnus both under Linux and Windows 2000, with the same result. Starting Gnus with 'M-x gnus-unplugged' doesn't improve the situation, which means that Gnus is not so slow because of a network. Any ideas what can be wrong so that a performance degrades so much - or is it possible somehow to check what is wrong (something like profiling)? Daniel. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 6:02 ` Daniel M. @ 2004-08-23 20:22 ` Jorge Godoy 0 siblings, 0 replies; 19+ messages in thread From: Jorge Godoy @ 2004-08-23 20:22 UTC (permalink / raw) Daniel M. <xt@nm.ru> writes: > Yes, I tried. Also, I tried to use Gnus both under Linux and > Windows 2000, with the same result. Starting Gnus with > 'M-x gnus-unplugged' doesn't improve the situation, which means > that Gnus is not so slow because of a network. > > Any ideas what can be wrong so that a performance degrades > so much - or is it possible somehow to check what is wrong > (something like profiling)? You'll need help from one of the gurus. ;-) I'm just a simple user. :-) Be seeing you, -- Godoy. <godoy@ieee.org> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-23 3:40 Gnus is very slow in displaying headers Daniel M. 2004-08-23 12:12 ` Jorge Godoy @ 2004-08-24 4:49 ` Kevin Greiner 2004-08-24 17:30 ` Daniel M. 2004-08-24 20:07 ` Jesper Harder 2004-08-26 14:50 ` ignotus 3 siblings, 1 reply; 19+ messages in thread From: Kevin Greiner @ 2004-08-24 4:49 UTC (permalink / raw) Daniel M. <xt@nm.ru> writes: > Hello everybody, > > I noticed that even when I enter a group with a relatively small > amount of headers - in my case, 12000 for comp.lang.lisp, it takes > Gnus a very long time to thread/load them (headers are already in > the spool - they were downloaded previously by the Gnus) - 3 minutes > and 100% CPU for the duration of that period. > > Forte Agent, for example, has no problem with groups which > contain hundreds of thousands of headers - it takes merely a couple > of seconds to load them, so it is not a lack of memory/CPU cycles. > > Am I doing something wrong, or is it a fundamental issue (elisp is too > slow? something in the core of X/Emacs?) which renders Gnus unusable > for anything more then a very small groups? The problem is mostly likely due to your setting for gnus-summary-line-format. This is a string that describes the fields displayed for each line of the summary buffer. Internally, gnus compiles this string into an elisp expression that inserts an article into the buffer. The approach is infinitely customizable but not very optimizable. You might look in the manual under 'Summary Buffer Lines' to see if can identify a simplier string; one that meets your requirements yet offers better performance. > After searching the group for a similar questions, I saw an advice > to set nntp-marks-is-evil variable to 't', which I have done, but > it made no noticable difference. Right. Nothing to do with your problem. > I use Gnus 5.10.6 on Debian (precompiled package from unstable). > > BTW, listing of all active groups (zombie, killed groups - I am not > sure how I am supposed to call them. In effect, it is the list of all > groups carried by the server) also takes a lot of time - almost a full > minute, although there are only ~32000 groups and the file containing > them resides on the HD. I even tried to sort that file, but it didn't > help :(. I see the same thing, I just don't display the active list often enough to try to optimize it. Kevin ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 4:49 ` Kevin Greiner @ 2004-08-24 17:30 ` Daniel M. 2004-08-24 9:31 ` Kai Grossjohann 0 siblings, 1 reply; 19+ messages in thread From: Daniel M. @ 2004-08-24 17:30 UTC (permalink / raw) >The problem is mostly likely due to your setting for >gnus-summary-line-format. This is a string that describes the fields >displayed for each line of the summary buffer. Internally, gnus >compiles this string into an elisp expression that inserts an article >into the buffer. The approach is infinitely customizable but not very >optimizable. You might look in the manual under 'Summary Buffer >Lines' to see if can identify a simplier string; one that meets your >requirements yet offers better performance. It indeed improves somewhat the performance but it is still far from usable. Here are the settings I have used and the time to load headers into a summary buffer (the group contained 12000 headers): (setq gnus-summary-line-format "") - 1 min. and 8 sec. (setq gnus-summary-line-format "\n") - 1 min. and 8 sec. (setq gnus-summary-line-format "%s\n") - 1 min. 37 sec. Setting gnus-show-threads to nil doesn't make any noticable difference. Using any other formatting options pushes loading time still higher. No matter what I tried, it doesn't take less then 2 minutes to load the group, even if the most basic usable summary formatting line was used. Is there are other ways to speed up the process? BTW, my computer's specs are: CPU: Athlon 1333, RAM: 768MB. Daniel. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 17:30 ` Daniel M. @ 2004-08-24 9:31 ` Kai Grossjohann 2004-08-24 19:44 ` Daniel M. 0 siblings, 1 reply; 19+ messages in thread From: Kai Grossjohann @ 2004-08-24 9:31 UTC (permalink / raw) Daniel M. <xt@nm.ru> writes: > Using any other formatting options pushes loading time still > higher. No matter what I tried, it doesn't take less then 2 minutes > to load the group, even if the most basic usable summary formatting > line was used. Does it help to put (gnus-compile) after the (setq gnus-summary-line-format ...) statement? Kai ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 9:31 ` Kai Grossjohann @ 2004-08-24 19:44 ` Daniel M. 2004-08-24 12:05 ` Kai Grossjohann 0 siblings, 1 reply; 19+ messages in thread From: Daniel M. @ 2004-08-24 19:44 UTC (permalink / raw) >Does it help to put (gnus-compile) after the (setq >gnus-summary-line-format ...) statement? Unfortunatley not at all - it still takes the same 1 min. 37 sec. to load the group. For 26 sec. the status line reads: "Fetching headers for comp.lang.lisp" (the group I ma loading), then for the rest of the time: "Generating summary". Daniel. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 19:44 ` Daniel M. @ 2004-08-24 12:05 ` Kai Grossjohann 2004-08-24 13:35 ` Derrell.Lipman 2004-08-25 6:26 ` Daniel M. 0 siblings, 2 replies; 19+ messages in thread From: Kai Grossjohann @ 2004-08-24 12:05 UTC (permalink / raw) Daniel M. <xt@nm.ru> writes: >>Does it help to put (gnus-compile) after the (setq >>gnus-summary-line-format ...) statement? > > Unfortunatley not at all - it still takes the same 1 min. 37 sec. > to load the group. For 26 sec. the status line reads: "Fetching > headers for comp.lang.lisp" (the group I ma loading), then > for the rest of the time: "Generating summary". I see. I'm afraid that probably most people do not open groups with that many articles. The time used for summary generation depends on the length of the summary buffer. Some people like to keep lots of articles marked as unread, especially for mail, so that they do not lose track of the context. But I think that it works well to (setq gnus-fetch-old-headers t): this leads to Gnus showing the complete thread, if there is an unread article in that thread. This way, I get the complete context of new discussions, without having to keep all old articles of this discussion unread. So my question to you is: why are there 12,000 unread articles in that group? I'm suspecting that you don't intend to read them all... Kai ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 12:05 ` Kai Grossjohann @ 2004-08-24 13:35 ` Derrell.Lipman 2004-08-25 6:08 ` Daniel M. 2004-08-25 7:14 ` Kai Grossjohann 2004-08-25 6:26 ` Daniel M. 1 sibling, 2 replies; 19+ messages in thread From: Derrell.Lipman @ 2004-08-24 13:35 UTC (permalink / raw) Cc: ding Kai Grossjohann <kai@emptydomain.de> writes: > Some people like to keep lots of articles marked as unread, especially > for mail, so that they do not lose track of the context. But I think > that it works well to (setq gnus-fetch-old-headers t): this leads to > Gnus showing the complete thread, if there is an unread article in > that thread. This way, I get the complete context of new discussions, > without having to keep all old articles of this discussion unread. I used to do that. Based on a previous thread in the ding list about slow presentation of a group, I now have the following comment and setting in my .gnus file: (setq ;; Show headers of previous messages in a thread ;; Don't do this; it greatly slows down presentation of the group gnus-fetch-old-headers nil ) My recollection was that the difference in speed, disabling this, was remarkable. Derrell ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 13:35 ` Derrell.Lipman @ 2004-08-25 6:08 ` Daniel M. 2004-08-25 7:14 ` Kai Grossjohann 1 sibling, 0 replies; 19+ messages in thread From: Daniel M. @ 2004-08-25 6:08 UTC (permalink / raw) >I used to do that. Based on a previous thread in the ding list about slow >presentation of a group, I now have the following comment and setting in my >.gnus file: > > (setq > ;; Show headers of previous messages in a thread > ;; Don't do this; it greatly slows down presentation of the group > gnus-fetch-old-headers nil > ) > >My recollection was that the difference in speed, disabling this, was >remarkable. I tried setting that variable as you had advised, but it didn't have an impact on the speed. If I understand the documentation correctly, this variable has an impact only if there are 'read' articles - usually Gnus will construct threads using old, read articles if there are some unread articles in the thread. Setting that variable to 'nil' will prevent Gnus from loading the read articles. But in my case, almost all of the articles are unread - because of that, there is no noticeable difference. Daniel. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 13:35 ` Derrell.Lipman 2004-08-25 6:08 ` Daniel M. @ 2004-08-25 7:14 ` Kai Grossjohann 1 sibling, 0 replies; 19+ messages in thread From: Kai Grossjohann @ 2004-08-25 7:14 UTC (permalink / raw) Cc: ding Derrell.Lipman@UnwiredUniverse.com writes: > Kai Grossjohann <kai@emptydomain.de> writes: > >> Some people like to keep lots of articles marked as unread, especially >> for mail, so that they do not lose track of the context. But I think >> that it works well to (setq gnus-fetch-old-headers t): this leads to >> Gnus showing the complete thread, if there is an unread article in >> that thread. This way, I get the complete context of new discussions, >> without having to keep all old articles of this discussion unread. > > I used to do that. Based on a previous thread in the ding list about slow > presentation of a group, I now have the following comment and setting in my > .gnus file: > > (setq > ;; Show headers of previous messages in a thread > ;; Don't do this; it greatly slows down presentation of the group > gnus-fetch-old-headers nil > ) > > My recollection was that the difference in speed, disabling this, was > remarkable. Well, what do I say about this? Many people have many articles marked as unread. It is faster to mark them as read and (setq gnus-fetch-old-headers t) -- this tends to show the "interesting" articles that people would otherwise mark as unread. Obviously, not showing the "interesting" articles is faster still. But then, people might tend to mark interesting articles as unread, leading to 12,000 unread articles in a group, which leads to the slowdown. Kai ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 12:05 ` Kai Grossjohann 2004-08-24 13:35 ` Derrell.Lipman @ 2004-08-25 6:26 ` Daniel M. 2004-08-24 20:54 ` Andrew A. Raines 2004-08-25 8:57 ` Kai Grossjohann 1 sibling, 2 replies; 19+ messages in thread From: Daniel M. @ 2004-08-25 6:26 UTC (permalink / raw) >So my question to you is: why are there 12,000 unread articles in that >group? I'm suspecting that you don't intend to read them all... > Usually I don't follow daily discussions in newsgroups closely. Instead, I fetch all headers from a group and browse through them, reading old posts that catch my interest. But sooner or later I would catch on those ones skipped previously, or get back to those already read - this is like a 'cookbook' or a reference: you don't read everything from the beginning to the end, but use it to glean the immediately useful information or to refresh your memory. For example, there are more then 160000 articles in linux.debian.user (on gmane's newsserver). Obviously, with the current summary generating speed it is impractical to try and read it with Gnus :(. Daniel. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-25 6:26 ` Daniel M. @ 2004-08-24 20:54 ` Andrew A. Raines 2004-08-25 8:57 ` Kai Grossjohann 1 sibling, 0 replies; 19+ messages in thread From: Andrew A. Raines @ 2004-08-24 20:54 UTC (permalink / raw) Daniel M. <xt@nm.ru> writes: [...] > Usually I don't follow daily discussions in newsgroups > closely. Instead, I fetch all headers from a group and browse > through them, reading old posts that catch my interest. Wow. Isn't that similar to entering random URLs in your web browser to find interesting sites? USENET doesn't work well like that. I would suggest running through groups you don't follow closely every week or two with your fingers on C-k, stopping on threads that interest you. If looking through thousands of messages is your thing, take heart; debian-user can easily provide 1000-1500 per week. Leave finding the old, interesting content to Google. -- aaraines@pobox.com (Andrew A. Raines) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-25 6:26 ` Daniel M. 2004-08-24 20:54 ` Andrew A. Raines @ 2004-08-25 8:57 ` Kai Grossjohann 1 sibling, 0 replies; 19+ messages in thread From: Kai Grossjohann @ 2004-08-25 8:57 UTC (permalink / raw) Daniel M. <xt@nm.ru> writes: >> So my question to you is: why are there 12,000 unread articles in that >> group? I'm suspecting that you don't intend to read them all... > > Usually I don't follow daily discussions in newsgroups closely. Instead, > I fetch all headers from a group and browse through them, > reading old posts that catch my interest. But sooner or later I would > catch on those ones skipped previously, or get back to those already > read - this is like a 'cookbook' or a reference: you don't read everything > from the beginning to the end, but use it to glean the immediately > useful information or to refresh your memory. I see. This means that it is a one-time only thing, until you were able to catch up on those articles. Note that you can use scoring, or adaptive scoring, to keep down the number of articles you read, once you have started reading the group. But for the initial part, I don't know of a way to make it faster with Gnus. As far as I'm concerned, myself, I just hit c before I start reading a group, because reading (even skimming) 12,000 articles is out of the question for me. Kai ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-23 3:40 Gnus is very slow in displaying headers Daniel M. 2004-08-23 12:12 ` Jorge Godoy 2004-08-24 4:49 ` Kevin Greiner @ 2004-08-24 20:07 ` Jesper Harder 2004-08-25 6:34 ` Daniel M. 2004-08-26 14:50 ` ignotus 3 siblings, 1 reply; 19+ messages in thread From: Jesper Harder @ 2004-08-24 20:07 UTC (permalink / raw) Daniel M. <xt@nm.ru> writes: > I noticed that even when I enter a group with a relatively small > amount of headers - in my case, 12000 for comp.lang.lisp, it takes > Gnus a very long time to thread/load them (headers are already in > the spool - they were downloaded previously by the Gnus) - 3 minutes > and 100% CPU for the duration of that period. You *are* running a byte compiled Gnus, right? (i.e. you used the Makefile to build it, ./configure && make). -- Jesper Harder <http://purl.org/harder/> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-24 20:07 ` Jesper Harder @ 2004-08-25 6:34 ` Daniel M. 0 siblings, 0 replies; 19+ messages in thread From: Daniel M. @ 2004-08-25 6:34 UTC (permalink / raw) On Tue, 24 Aug 2004 22:07:58 +0200, Jesper Harder <harder@ifa.au.dk> wrote: >You *are* running a byte compiled Gnus, right? (i.e. you used the >Makefile to build it, ./configure && make). I suppose so. On Linux, I use Debian's package which includes Gnus (it comes with Xemacs, from an unstable distribution). On Windows it also included in Xemacs, and comes bundled with a binary package from Xemacs' site. Both versions contain files with .elc extensions. Daniel. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-23 3:40 Gnus is very slow in displaying headers Daniel M. ` (2 preceding siblings ...) 2004-08-24 20:07 ` Jesper Harder @ 2004-08-26 14:50 ` ignotus 2004-08-27 23:24 ` Daniel M. 3 siblings, 1 reply; 19+ messages in thread From: ignotus @ 2004-08-26 14:50 UTC (permalink / raw) >>>>> Daniel M. wrote: > I noticed that even when I enter a group with a relatively small > amount of headers - in my case, 12000 for comp.lang.lisp, it takes > Gnus a very long time to thread/load them [...] Yes, the sad fact is that Gnus is that slow and it doesn't matter what you do you can't bring it up to the ,,normal speed'' (which means under 1 second), not even close to it. Heh, I still remember my horror when I first saw the speed of Gnus after using Mutt / slrn. With Mutt/slrn threading / displaying a message etc takes no time, you have all the time for yourself to actually *read* the messages and it feels good. I tried to do that with Gnus, trimmed down all the features I thought I didn't absolutely need etc but of course it was still extremely slow. But I sticked with it because it was so much more configurable, I saw at the time that with an Emacs based software the limit is my imagination, while with Mutt / slrn / etc the limit is the configuration options the developers decide to impelement. So as my elisp knowledge grew I customized Gnus bit by bit to my tastes, and of course Gnus became slower and slower but I was able to subscribe to more and more newsgroups / mailing lists. You may know already what happened to me. While mutt / slrn maximizes the time you have for reading by not ,,interrupting you'' with long computations, Gnus minimizes the time you will need to read the messages by having so much ,,time-saving'' features (adapting scoring is a godsend). And after you experienced both, I can assure you that the latter feels better. ;) So the moral of the story is that while Gnus is slow, following the same volume of messages with mutt / slrn isn't possible for me because it would take so much of my time. And for those who don't understand why would someone in his right mind read 12k messages: please never forget about the faceless, voiceless and lifeless masses of ,,Usenet junkies''. :-) -- ...sutongi tti olleh If you are smart enough to know that you're not smart enough to be an Engineer, then you're in Business. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Gnus is very slow in displaying headers. 2004-08-26 14:50 ` ignotus @ 2004-08-27 23:24 ` Daniel M. 0 siblings, 0 replies; 19+ messages in thread From: Daniel M. @ 2004-08-27 23:24 UTC (permalink / raw) >Yes, the sad fact is that Gnus is that slow and it doesn't matter what >you do you can't bring it up to the ,,normal speed'' (which means under >1 second), not even close to it. Maybe one day X/Emacs would be fitted with Common Lisp backend having a native-code compiler - then probably the speed would improve sufficiently for Gnus to be usable with bigger groups: for the time being, though, it seems that Gnus is not for me :(. I don't understand, though, why summary buffers have to be generated afresh every time you enter a group - it seems to me that generating it once, saving to HD and then adding/removing chunks from it when needed (for example, when new headers arrive, some articles are read etc.) should speed the things up immensely. Also, it looks to me like a good idea to have a command line option which will cause regeneration of summary buffers (if summary buffers are saved to HD). Then, if user decides to change summary buffer's format line, he can say, for example: 'xemacs --gnus-regenerate-summary-buffers', then go and have a (long) lunch, after which he can come back and start reading his dose of news without waiting for regeneration of summary buffers. >I tried to do that with Gnus, trimmed down all the features I thought I >didn't absolutely need etc but of course it was still extremely slow. >But I sticked with it because it was so much more configurable, I saw at >the time that with an Emacs based software the limit is my imagination, >while with Mutt / slrn / etc the limit is the configuration options the >developers decide to impelement. Well, you can add whatever options you want by simply modifying slrn's source code - some people have done exactly that (see http://www.xs4all.nl/~thunder7/, for example). Maybe it is easier to do in elisp, but if you are well familiar with GNU's development chain (which I, at least, am not), it shouldn't be a big problem. >You may know already what happened to me. While mutt / slrn maximizes >the time you have for reading by not ,,interrupting you'' with long >computations, Gnus minimizes the time you will need to read the messages >by having so much ,,time-saving'' features (adapting scoring is a >godsend). And after you experienced both, I can assure you that the >latter feels better. ;) Don't think it will work for me - by the time the group is loaded, the time allocated for my news reading would probably be up :^). Daniel. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2004-08-27 23:24 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-08-23 3:40 Gnus is very slow in displaying headers Daniel M. 2004-08-23 12:12 ` Jorge Godoy 2004-08-24 6:02 ` Daniel M. 2004-08-23 20:22 ` Jorge Godoy 2004-08-24 4:49 ` Kevin Greiner 2004-08-24 17:30 ` Daniel M. 2004-08-24 9:31 ` Kai Grossjohann 2004-08-24 19:44 ` Daniel M. 2004-08-24 12:05 ` Kai Grossjohann 2004-08-24 13:35 ` Derrell.Lipman 2004-08-25 6:08 ` Daniel M. 2004-08-25 7:14 ` Kai Grossjohann 2004-08-25 6:26 ` Daniel M. 2004-08-24 20:54 ` Andrew A. Raines 2004-08-25 8:57 ` Kai Grossjohann 2004-08-24 20:07 ` Jesper Harder 2004-08-25 6:34 ` Daniel M. 2004-08-26 14:50 ` ignotus 2004-08-27 23:24 ` Daniel M.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).