Announcements and discussions for Gnus, the GNU Emacs Usenet newsreader
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: info-gnus-english@gnu.org
Subject: Re: how can I keep gnus from Hiding All Threads when open a group
Date: Sun, 04 Jun 2017 09:31:38 +0800	[thread overview]
Message-ID: <871sr0v8qt.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <8660gdgegb.fsf@local.lan>

Harry Putnam <reader@newsguy.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Harry Putnam <reader@newsguy.com> writes:
>>
>>> I notice when I open a group, gnus hides all threads seemingly
>>> automatically.
>>>
>>> But when opening really large groups; 12,000 and up, even 50,000 msgs
>>> that process of hiding all threads can become a hefty time sink.
>>>
>>> Even when unplugged and all the messages are already downloaded.
>>>
>>> How could I go about telling gnus to leave the threads unhidden or
>>> would that have the effect I'm hoping for... i.e. speeding up opening
>>> really large groups.
>>
>> I'm not quite sure what you mean by "hiding" -- do you mean the threads
>> are folded? Like you only see the top message in the thread and have to
>> expand it to see the rest?
>
> Yes.
>
> I got the terminology from gnus itself.... when I open a large group
> After showing a message about generating the summary buffer, it shows
> a message of `Hiding all threads' and then a count usually only
> displays the thousands.

Ah I see. I don't use this and didn't realize it was the normal term.

>> Anyway, I doubt this is the source of the slowdown -- asking Gnus to
>> display 50,000 messages in a summary buffer is going to be slow no
>> matter what. Turning off threading altogether should help some, but
>> that's all I can say.
>
> I do realize that groups of that size are really really slow.
> I have some experience in that area.
>
> However unless the `hiding all threads' message is misleading and
> doesn't really have anything to do with what is happening, I can see
> the wait growing longer by watching `hiding all threads'; 1000 ...
> ...2000 ....3000 the waits between are relatively short but after about
> 4000 the waits between ouput grow exponentially.  Getting up to 7/8
> thousand the wait between 7 and 8000 is quite lengthy.  I haven't
> timed it or I'd post the times.
>
> That's what gave me the idea of cutting out the thread hiding.... Also,
> must of what I do in there means I have to SHOW threads anyway `T S'
> so I have to undo the Hiding anyway.
>
> Writing that made me think it might be a setting of my own doing.
>
> Can one set how threads are displayed when a group is opened?

Okay, well that certainly makes it sound like thread hiding really is
the source of the problem. It looks like setting
`gnus-thread-hide-subtree' to nil will do what you want. But I'd
definitely recommend playing with `gnus-show-threads' and
`gnus-fetch-old-headers' (and maybe try `gnus-build-sparse-threads'),
and see which combination of settings gets you the fastest load.

No matter what, I think the main recommendation would be to try to open
group buffers with fewer messages! Is it really necessary to display
tens of thousands of messages each time?

E



  reply	other threads:[~2017-06-04  1:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-02 20:39 Harry Putnam
2017-06-03  3:58 ` Eric Abrahamsen
2017-06-03 17:37   ` Harry Putnam
2017-06-04  1:31     ` Eric Abrahamsen [this message]
2017-06-16 21:28       ` Harry Putnam
2017-06-17  1:35         ` Eric Abrahamsen
2017-06-17 18:24           ` Harry Putnam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871sr0v8qt.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=info-gnus-english@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).