Re: Gnus docs questions/notes

[David Abrahams <dave@boost-consulting.com>]

Lars,

Thanks so much for responding!

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> I realize that _some_ of what I'm asking for may be outside the charter
>> of this document as described in 15.4, "On Writing Manuals," but it's
>> the only comprehensive document we have AFAIK, so it may make sense to
>> improve it rather than wait for someone to write something that's more
>> like a "user's guide."
>
> Well, there have been quite a few "user guide" style documents that
> cover various parts of Gnus on the web.  my.gnus.org collects quite a
> few of these.

Yes, IIRC they are all too scattered and leave out too much
fundamental information for me to really get a grip on Gnus.  Looking
at them again, they definitely deserve to be revisited.  I will
understand much more of what I'm reading in your docs after I've
looked at them all.  But your docs should be understandable on their
own.  The tutorial/howtos are not really designed to be a concept
reference for the main Gnus docs ;-)

> It's apparently easier to write HTML than TeXinfo.  :-)

Pshaw.  It's easier to do what you already know than to learn new things.

>> Section 1.1 Finding the news
>>
>> - Page numbering is restarted somewhere in gnus-manual-standard.pdf, so
>> that the reference on page 2 to the Terminology section points to page
>> 113, but there's no indication of the restart.  That's confusing.
>
> Generating the pdf is a pain, but I'll give it a go...
>
> Hm...  there doesn't seem to be any text on my page two.

It's the (first) page with the number 2 printed on it.  The 21st page
of my PDF.

>> - p.2 mentions "the local spool."  What's a spool?  It's not covered in
>> the terminology section
>
> Added..
>
>> - p.2 mentions "Leafnode."  It would be nice to have at least a short
>> footnote that says what that is.
>
> I've added a parenthesis.  I'm not really sure it's necessary; if you
> don't know what it is, you're not running it, and you definitely
> don't need that advice.  (Which really belongs in a FAQ instead.)

Then move it to a FAQ (?)

>> - p.3 mentions "active files." I realize this is defined in the
>> terminology section, but it would be nice if newly-introduced terms
>> could be cross-referenced to their definitions.
>
> Yes...  but I think this sort of thing really would be better handled
> if an editor(ish) type of person would read over the manual and just
> rearrange things and add links.  It's less work doing that than
> describing what the problem is.  

I agree, but here's the thing: the original author doesn't learn
how to do better in the future if the editor doesn't spell these
things out.  

> (TeXinfo is really quite easy to work with.  Hint, hint.  :-)
> Patches welcome.)

That said, your writing is about a thousand times better
than most of the people I do this for, so if you're willing to answer
a few "how do I..." TeXinfo questions and get me repository access
I'll gladly do this as I work my way through the docs.

>> It isn't clear whether the active file is typically stored on the
>> machine where Gnus is running or on the server; the answer could
>> greatly affect how I decide to make many Gnus settings, since active
>> files can grow so large.
>
> It all depends on how your setup is like.  If the (nntp) server is
> local, then the active file is.  If not, then not...

Then it's just stored on the server, and isn't as complicated as
you're making it out to be.  

Regardless, the point of my saying it is unclear was to prompt you to
clarify it (even if you have to give the complicated explanation for
some reason).

>> Section 1.2 The First Time
>>
>> - By "startup files" do you mean .gnus et. al?
>
> Yes.  There's a section called "Startup Files" that talks about all
> this.  I've added a reference to that.

Great.

>> - "If gnus-default-subscribed-newsgroups is t, Gnus will just use the
>> normal functions for handling new groups, and not do anything special."
>> This is too vague.  It's unclear what these normal functions might be,
>> nor what special things might have happened otherwise.
>
> It's a very vague section, meant to give a brief, readable overview
> of what's supposed to be happening.  I was trying to write a user
> manual at the time.

How about just describing what happens if
gnus-default-subscribed-newsgroups is NOT t? that will avoid most of
the vaguery by not needing to make reference to the normal mode of
operation.

>> 1.5 Fetching a Group
>>
>> - why might this be more useful for someone who writes code than for users?
>
> Because you have to know what the group name is.  That section
> shouldn't be in chapter one at all.  I'll move it.

Thank you.

>> - does it start Gnus?  If not, and you can read a group without starting
>> Gnus, what does it mean to start Gnus?
>
> That's also not something that's really well defined.  The function
> in question can't really be said to meaningfully start Gnus.

OK.

>> 1.6.1 Checking New Groups
>>
>> The news servers I use have so many groups on them, and I have so much
>> incoming traffic, that it's hard to imagine anyone wanting to have Gnus
>> automatically subscribe them to new groups.  Is this really a common
>> usage pattern?
>
> No, I think not.  But back in 1987, it probably was.

This section should probably be reorganized with common usage patterns
in mind, then.

>> From reading the docs, it seems like there's a lot of expensive
>> computation and storage devoted to being able to do that in Gnus,
>> and it's all turned on by default.
>
> Gnus makes new groups into zombies by default, which is quite cheap.
> And it doesn't read the entire active file by default, so I think it
> might be doing the right thing.

Okay.  It might be a good idea to head this concern off at the pass by
saying so.

>> 1.8 Startup Files
>>
>> - Begins, "Now, you all know about the `.newsrc' file."  Well, not
>> really.  I don't know much about it at all yet.  The statement makes me
>> wonder what I *should* know about it at this point, and where I ought to
>> go to find that information.
>
> Heh.  That shows my geeky bias.  When I started doing Gnus, I don't
> think anybody who read news wouldn't have known what the .newsrc file
> was.  But times change...
>
> I've changed this to
>
> ---
> Most common Unix news readers use a shared startup file called
> @file{.newsrc}.  This file contains all the information about what
> groups are subscribed, and which articles in these groups have been
> read. 
> ---

Very nice!

>> - "You can turn off writing the ‘.newsrc’ file by setting
>> gnus-save-newsrc-file to nil, which means you can delete the file and
>> save some space, as well as exiting from Gnus faster. However, this will
>> make it impossible to use other newsreaders than Gnus."
>>
>> This baffles me.  How could telling Gnus not to touch .newsrc prevent me
>> from using other newsreaders?
>
> Well, they wouldn't know what articles you've read, or what groups
> you're subscribed to.  That's not impossible, but it's certainly
> painful... 

It's worth noting that plenty of newsreaders won't look at .newsrc,
for example, almost any newsreaders running on Windows, so the
statement is just completely wrong in that context.

It would be far less confusing to simply say that "if you turn off
writing the .newsrc file, other newsreaders that use the file won't
know which articles you've already read in Gnus."

>> - "Similarly, setting gnus-read-newsrc-file to nil makes Gnus ignore the
>> ‘.newsrc’ file and any ‘.newsrc-SERVER’ files, which is convenient if
>> you have a tendency to use Netscape once in a while."
>>
>> Why is that convenient for people who use Netscape once in a while?
>
> Because Netscape writes those files, and have a tendency to write
> totally bogus info there.  But it's probably outdated info by now.
> I've changed it.

It should just say "Gnus won't know which articles you've read in
other newsreaders that use .newsrc"

IMO this part's clarity suffered from a desire to maintain a playful
tone.

>> - "You should always set gnus-check-new-newsgroups to nil or ask-server
>> if you set this variable to nil (see “New Groups” on page 5). This
>> variable can also be a regular expression. If that’s the case, remove
>> all groups that do not match this regexp before saving."
>>
>> Is this an instruction to me, the user, or is it really telling me what
>> Gnus will do if gnus-check-new-newsgroups is a regexp?  Before saving
>> what?  Remove the groups from where?
>
> It's talking about `gnus-save-killed-list', so the "remove" is from
> the variable that's controlling.  I.e., the list of killed groups.

I can't quite tell if you're giving me, the reader, an instruction to
do that removal.  What are the consequences of doing/not doing that
removal?

>> - The gnus-startup-file variable says where the startup files are. The
>> default value is ‘˜/.newsrc’, with the Gnus (El Dingo) startup file
>> being whatever that one is, with a “.eld” appended.
>>
>> What is El Dingo?
>
> A joke.  :-)  

IMO this part's clarity suffered from a desire to maintain a playful
tone.  Sorry to seem humorless, but unless the reader is likely to get
the joke, it's not working.

>> 1.10 The Active File
>>
>> I'm trying to figure out how to set gnus-read-active-file for my primary
>> select method, which will be an IMAP server.  I assume that's neither
>> Leafnode nor INN, so none of the information here applies to me.
>
> I don't think you have to do anything in particular for that, really.
>
> (setq gnus-select-method '(nnimap "your.imap.server"))
>
> The defaults should be OK.

It would be a good idea to let people know up front that special
procedures are only required for NNTP(?) servers running Leafnode or
INN, so they don't wonder.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com