Re: What's a killed article ?

[Ted Zlatanov]

On Thu, 18 Dec 2008 21:00:52 +0100 harven <harven@free.fr> wrote: 

h> From the top of my head, some terms, either ambiguous or defined too
h> late in the manual

(note the below are thoughts that can go into the manual eventually, but
I think it's too early)

h> - MAIL BACK END (info "(gnus)Comparing mail back ends") The list of
h>   all available mail backends should be given sooner The following
h>   list appears in 1.5.3 (`nnml', `nnbabyl', `nnfolder',
h>   `nnmbox',`nnmh', and `nnmaildir') but nnimap is also mentioned in
h>   3.22 and others are alluded to at 6.3.13 It would be nice if real
h>   life config examples were given for each of them and if their
h>   different features and limitations were summarized somewhere.

I think a full backend list is useful and should probably be referenced
at the front of the manual ("here's what Gnus can do...") but it should
not live there.  OTOH, the full list of protocols that Gnus can handle
is urgently needed by new users and should probably be in the first
section (with references to the later chapters that define them).  I
agree about configuration examples too.

"back end" is defined early in the Terminology appendix, by the way.
That's where updated definitions we discuss here will go.  Do you think
the definition is poor?

h> For example, I tried to use nnmbox to browse some archive and got the
h> following: Article mail.misc:1190 out of order. This seems specific
h> to that backend, and still mysterious for me.

I don't know what causes that, I don't use nnmbox, sorry.

h> - IDLE (info "(gnus)Daemons")
h>   what does exactly idle means ? Can really emacs be idle ? 
h>   Is emacs idle between that short time separating two keystrokes ? 
h>   Fetching mail freezes emacs, some warning and comments 
h>   would be welcome here.

Unfortunately "IDLE" has an IMAP meaning too.  Specifically for Daemons,
"idle" means that Emacs is not busy running ELisp code.  Emacs can
indeed be idle, and it can do things automatically at those times.  It's
not idle between consecutive ELisp function calls, but it's idle between
two keystrokes (font-lock uses that, for example).

Asynchronous mail retrieval is indeed a badly needed feature.  What
should we say/promise/warn?  It's basically a statement of "we know
Emacs as a whole freezes while you get your mail, sorry."

h> - GNUS-SECONDARY-SELECT-METHODS
h>   and gnus-select-method. A single select method but many secondary
h>   methods ? Why  differentiate ? 

For better or worse, Gnus has made the decision that the primary select
method will have unqualified group names.  Thus, if you have a group
"mail", it really refers to "primary_select_method:mail".  All secondary
select methods are full (including the select method's name).  I think
it's best to use nnil as the primary and have all the groups look the
same, fully qualified, but I'm sure many people like the brevity of the
primary select method.

h> Is it correct to put a mail group as the primary method ? 

Yes, and Gnus backend can be used AFAIK.

h> In the following 
h> (setq gnus-select-method '(nntp "news.yourprovider.net"))
h> "news.yourprovider.net" is the address used for news retrieval

Correct.

h> whereas dolk is not the address for retrieval in 
h> (setq gnus-secondary-select-methods 
h> '((nnimap "dolk" (nnimap-address "localhost") (nnimap-server-port 1430))))

Correct.  The address is inferred from the method name if it's not
specified otherwise; in addition each backend has its own way of
specifying the address.

h> Or is it ? There are reports in this newsgroup of people getting in
h> trouble if "dolk" is used instead of the nnimap address.  I ran into
h> that problem once.

I remember these reports.  They are bugs and should be filed as such; I
thought they were resolved but I may be wrong.

h> BTW I think it would be better to improve the GnusTutorial on
h> emacswiki instead of modifying the Gnus manual.

Generally, it's been accepted by Gnus developers that the manual should
not depend on external resources.  The tutorial would be bundled with
the manual, so I don't think it should live on an external site.  The
external site, however, could be kept in sync on CVS commits or manually.

On Tue, 23 Dec 2008 10:17:07 +0200 Giorgos Keramidas <keramida@ceid.upatras.gr> 
wrote: 

GK> My gut feeling is that the Gnus manual has *everything* but it is
GK> written more like a reference and not really as a tutorial.  Maybe it
GK> would be worth writing an accompanying manual, i.e. something called
GK> `gnus-tutorial.info', that we can point new users to :-)

I agree.  It's very hard for someone who doesn't understand the basics
of Emacs Lisp to configure Gnus.  I tried to push the Gnus assistants
(see assistant.el) but there's been no interest in them after I made my
initial proposals and Lars wrote a good version.

Ted