From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/88187 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: `gnus-build-sparse-threads' docstring Date: Thu, 18 Oct 2018 09:41:36 -0700 Message-ID: <87bm7r437j.fsf@ericabrahamsen.net> References: <877eifwe6r.fsf@portable.galex-713.eu> <87va5zuyt6.fsf@portable.galex-713.eu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1539880810 16793 195.159.176.226 (18 Oct 2018 16:40:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Oct 2018 16:40:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: ding@gnus.org Original-X-From: ding-owner+M36401@lists.math.uh.edu Thu Oct 18 18:40:06 2018 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from lists1.math.uh.edu ([129.7.128.208]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDBL9-00046s-Dx for ding-account@gmane.org; Thu, 18 Oct 2018 18:40:03 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.90_1) (envelope-from ) id 1gDBMz-0007dY-D9; Thu, 18 Oct 2018 11:41:57 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gDBMq-0007ag-Ns for ding@lists.math.uh.edu; Thu, 18 Oct 2018 11:41:48 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gDBMp-0004bh-2y for ding@lists.math.uh.edu; Thu, 18 Oct 2018 11:41:48 -0500 Original-Received: from [195.159.176.226] (helo=blaine.gmane.org) by quimby.gnus.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDBMn-0005yh-RE for ding@gnus.org; Thu, 18 Oct 2018 18:41:45 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gDBKf-0003dp-G6 for ding@gnus.org; Thu, 18 Oct 2018 18:39:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 39 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Jqo3CqRS2ij7VDEFlOr4teRPWRc= X-Spam-Score: -0.9 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:88187 Archived-At: "Garreau, Alexandre" writes: > On 2018/10/18 at 15:57, Garreau, Alexandre wrote: >> >> When putting a raw symbol, not to be evaluated, in docstring, >> `describe-variable' highlights these as links to same-name symbol >> description (`describe-symbol'). Yet in `gnus-build-sparse-threads', >> “'some” doesn’t refer to `some' (the cl function, alias for `cl-some'), >> so I guess it would be more correctly written as “'some” or 'some >> directly, instead of `some'. > > Also I find the docstring rather less explanative about the use of > “'all”/t (what’s the difference with “more”?), see afterwards: > > Docstring: > "*If non-nil, fill in the gaps in threads. > If `some', only fill in the gaps that are needed to tie loose threads > together. If `more', fill in all leaf nodes that Gnus can find. If > non-nil and non-`some', fill in all gaps that Gnus manages to guess." > > Manual: > Fetching old headers can be slow. A low-rent similar effect can be > gotten by setting this variable to ‘some’. Gnus will then look at > the complete ‘References’ headers of all articles and try to string > together articles that belong in the same thread. This will leave > “gaps” in the threading display where Gnus guesses that an article > is missing from the thread. (These gaps appear like normal summary > lines. If you select a gap, Gnus will try to fetch the article in > question.) If this variable is ‘t’, Gnus will display all these > “gaps” without regard for whether they are useful for completing > the thread or not. Finally, if this variable is ‘more’, Gnus won’t > cut off sparse leaf nodes that don’t lead anywhere. This variable > is ‘nil’ by default. I agree this is a little confusing, particularly regarding the difference between `some' and `more'. I guess `some' will only collect unread messages together, while `more' will do that, but also pull in sibling messages (?), while `all' will try to travel all the way up to the thread roots. Maybe.