From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/59672 Path: main.gmane.org!not-for-mail From: David Abrahams Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus docs questions/notes Date: Fri, 28 Jan 2005 13:28:15 -0500 Message-ID: References: <41E9AD33.5010306@boost-consulting.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1106937447 32672 80.91.229.6 (28 Jan 2005 18:37:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Jan 2005 18:37:27 +0000 (UTC) Original-X-From: ding-owner+M8212@lists.math.uh.edu Fri Jan 28 19:37:18 2005 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cuaze-0001dI-00 for ; Fri, 28 Jan 2005 19:37:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1Cuara-0001ji-00; Fri, 28 Jan 2005 12:28:58 -0600 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1CuarR-0001ja-00 for ding@lists.math.uh.edu; Fri, 28 Jan 2005 12:28:49 -0600 Original-Received: from quimby.gnus.org ([80.91.224.244]) by util2.math.uh.edu with esmtp (Exim 4.30) id 1CuarI-0003Cc-7V for ding@lists.math.uh.edu; Fri, 28 Jan 2005 12:28:40 -0600 Original-Received: from main.gmane.org ([80.91.224.249]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1CuarG-0007JX-00 for ; Fri, 28 Jan 2005 19:28:38 +0100 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CuarG-0008Dz-00 for ; Fri, 28 Jan 2005 19:28:38 +0100 Original-Received: from 146-115-127-135.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com ([146.115.127.135]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Jan 2005 19:28:38 +0100 Original-Received: from dave by 146-115-127-135.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Jan 2005 19:28:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: ding@gnus.org Original-Lines: 262 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 146-115-127-135.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (windows-nt) Cancel-Lock: sha1:4QN5y61QZxdbkhMREGkfIsm9dxw= Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: main.gmane.org gmane.emacs.gnus.general:59672 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:59672 Lars, Thanks so much for responding! Lars Magne Ingebrigtsen writes: > David Abrahams 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