What's a killed article ?

What's a killed article ?

[Francis Moreau]

Hello,

I can't find (easily) any definitions of this.

Info mentions a couple of time the work 'killed' for an article but I
have no clue what
does this mean... I understand expired, read, deleted but killed
sounds special.

Could anybody enlight me ?

thanks

Francis 

Re: What's a killed article ?

[Reiner Steib]

On Wed, Dec 03 2008, Francis Moreau wrote:

> Hello,
>
> I can't find (easily) any definitions of this.
>
> Info mentions a couple of time the work 'killed' for an article 

Please specify the paragraph(s) in the manual.  This one?

,----[ (info "(gnus)Read Articles") ]
| `K'
|      Marked as killed (`gnus-killed-mark').
`----

> but I have no clue what does this mean... I understand expired,
> read, deleted but killed sounds special.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: What's a killed article ?

[Francis Moreau]

Reiner Steib <reinersteib+from-uce@imap.cc> writes:

> On Wed, Dec 03 2008, Francis Moreau wrote:
>
>> Hello,
>>
>> I can't find (easily) any definitions of this.
>>
>> Info mentions a couple of time the work 'killed' for an article 
>
> Please specify the paragraph(s) in the manual.  This one?
>
> ,----[ (info "(gnus)Read Articles") ]
> | `K'
> |      Marked as killed (`gnus-killed-mark').
> `----
>
>> but I have no clue what does this mean... I understand expired,
>> read, deleted but killed sounds special.

yes this one.

thanks

Francis

Re: What's a killed article ?

[Reiner Steib]

On Thu, Dec 04 2008, Francis Moreau wrote:

> Reiner Steib <reinersteib+from-uce@imap.cc> writes:
>> On Wed, Dec 03 2008, Francis Moreau wrote:
>>> I can't find (easily) any definitions of this.
>>>
>>> Info mentions a couple of time the work 'killed' for an article 
>>> but I have no clue what does this mean... I understand expired,
>>> read, deleted but killed sounds special.
>
> yes this one.
[ (info "(gnus)Read Articles") ]

This is the mark used when you kill an article or thread:

,----[ (info "(gnus)Setting Marks") ]
| `M k'
| `k'
|      Mark all articles that have the same subject as the current one
|      as read, and then select the next unread article
|      (`gnus-summary-kill-same-subject-and-select').
`----

If you don't use adaptive scoring, there's no difference to mark the
article read using `d', I think.  If you use adaptive scoring it will
create corresponding score entries, see gnus-killed-mark in (info
"(gnus)Adaptive Scoring").

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: What's a killed article ?

[Francis Moreau]

Reiner Steib <reinersteib+from-uce@imap.cc> writes:

> On Thu, Dec 04 2008, Francis Moreau wrote:
>
>> Reiner Steib <reinersteib+from-uce@imap.cc> writes:
>>> On Wed, Dec 03 2008, Francis Moreau wrote:
>>>> I can't find (easily) any definitions of this.
>>>>
>>>> Info mentions a couple of time the work 'killed' for an article 
>>>> but I have no clue what does this mean... I understand expired,
>>>> read, deleted but killed sounds special.
>>
>> yes this one.
> [ (info "(gnus)Read Articles") ]
>
> This is the mark used when you kill an article or thread:
>
> ,----[ (info "(gnus)Setting Marks") ]
> | `M k'
> | `k'
> |      Mark all articles that have the same subject as the current one
> |      as read, and then select the next unread article
> |      (`gnus-summary-kill-same-subject-and-select').
> `----
>
> If you don't use adaptive scoring, there's no difference to mark the
> article read using `d', I think.  If you use adaptive scoring it will
> create corresponding score entries, see gnus-killed-mark in (info
> "(gnus)Adaptive Scoring").
>

Thanks Reiner.

It's sad to see that such notion are left undefined until a late
section (SCORING).

I really found the gnus info documentation hard to read. Are there any
other documentation about gnus out there ?

Francis

Re: What's a killed article ?

[Ted Zlatanov]

On Thu, 04 Dec 2008 22:46:32 +0100 Francis Moreau <francis.moro@gmail.com> wrote: 

FM> It's sad to see that such notion [killed articles] are left
FM> undefined until a late section (SCORING).

To me it was obvious, but I had been using tin for many years when I
tried Gnus, and in tin the names are similar IIRC.  Things like score
files, threads, and article marks are often assumed to be basic
knowledge in newsreader manuals.

I don't know if the Gnus manuals should remedy that or point to an
external reference for these terms.

FM> I really found the gnus info documentation hard to read. Are there
FM> any other documentation about gnus out there ?

You can look at the Emacs Wiki, and there have been a few articles
written over the years you can find with Google.  I don't know of
anything else.

Ted

Re: What's a killed article ?

[Francis Moreau]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 04 Dec 2008 22:46:32 +0100 Francis Moreau <francis.moro@gmail.com> wrote: 
>
> FM> It's sad to see that such notion [killed articles] are left
> FM> undefined until a late section (SCORING).
>
> To me it was obvious, but I had been using tin for many years when I
> tried Gnus, and in tin the names are similar IIRC.  Things like score
> files, threads, and article marks are often assumed to be basic
> knowledge in newsreader manuals.

So are you meaning that Gnus is for user that already had an
experience with another newsreader ?

> 
>
> I don't know if the Gnus manuals should remedy that or point to an
> external reference for these terms.

Yes definitely.

That said, it's not the only point where I find the documenation
obscure or not enough detailed: what's a very wide mail reply for
example. I can find ton of such example where you need to dig very
deeply the documentation to find such basic things, if the
documentation exists at all.

> You can look at the Emacs Wiki, and there have been a few articles
> written over the years you can find with Google.  I don't know of
> anything else.

Already tried unfortunately.

thanks

Francis

Re: What's a killed article ?

[Glyn Millington]

Francis Moreau <francis.moro@gmail.com> writes:

> That said, it's not the only point where I find the documenation
> obscure or not enough detailed: what's a very wide mail reply for
> example. 

,----
| 
| 3.5.1 Summary Mail Commands
| 
| Commands for composing a mail message:
| 
| S v
|     Mail a very wide reply to the author of the current article
|     (gnus-summary-wide-reply). A very wide reply is a reply that goes out
|     to all people listed in the To, From (or Reply-to) and Cc headers in
|     all the process/prefixed articles. This command uses the
|     process/prefix convention.
`----


That seems clear enough!



> I can find ton of such example where you need to dig very deeply the
> documentation to find such basic things, if the documentation exists at
> all.

I found the above by navigating to 

http://gnus.org/manual/big-gnus.html

and searching for "wide"

It wasn't too hard :-)

atb



Glyn

Re: What's a killed article ?

[Francis Moreau]

Glyn Millington <wistanswick@linuxmail.org> writes:

> Francis Moreau <francis.moro@gmail.com> writes:
>
>> That said, it's not the only point where I find the documenation
>> obscure or not enough detailed: what's a very wide mail reply for
>> example. 
>
> ,----
> | 
> | 3.5.1 Summary Mail Commands
> | 
> | Commands for composing a mail message:
> | 
> | S v
> |     Mail a very wide reply to the author of the current article
> |     (gnus-summary-wide-reply). A very wide reply is a reply that goes out
> |     to all people listed in the To, From (or Reply-to) and Cc headers in
> |     all the process/prefixed articles. This command uses the
> |     process/prefix convention.
> `----
>
>
> That seems clear enough!

Yes. I just looked at 'S V' definition...

Sorry.
-- 
Francis

Re: What's a killed article ?

[Ted Zlatanov]

On Fri, 05 Dec 2008 22:21:06 +0100 Francis Moreau <francis.moro@gmail.com> wrote: 

FM> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Thu, 04 Dec 2008 22:46:32 +0100 Francis Moreau <francis.moro@gmail.com> wrote: 
>> 
FM> It's sad to see that such notion [killed articles] are left
FM> undefined until a late section (SCORING).
>> 
>> To me it was obvious, but I had been using tin for many years when I
>> tried Gnus, and in tin the names are similar IIRC.  Things like score
>> files, threads, and article marks are often assumed to be basic
>> knowledge in newsreader manuals.

FM> So are you meaning that Gnus is for user that already had an
FM> experience with another newsreader ?

No, only that the manual assumes some basic knowledge.

>> I don't know if the Gnus manuals should remedy that or point to an
>> external reference for these terms.

FM> Yes definitely.

I don't know if the reference should be external or internally
contained, though.  Any opinions?

FM> That said, it's not the only point where I find the documenation
FM> obscure or not enough detailed: what's a very wide mail reply for
FM> example. I can find ton of such example where you need to dig very
FM> deeply the documentation to find such basic things, if the
FM> documentation exists at all.

OK, we can certainly put together a glossary and use the Texinfo
facilities to link terms to their definitions (I don't remember if
that's specifically supported but I'm sure something can be arranged).

Can you provide a list of terms you personally found challenging?
Remember, most readers of the Gnus mailing list and newsgroups are not
good test subjects for manual readability :)

Thanks
Ted

Re: What's a killed article ?

[Giorgos Keramidas]

On Mon, 08 Dec 2008 09:46:22 -0600, Ted Zlatanov <tzz@lifelogs.com> wrote:
> Can you provide a list of terms you personally found challenging?
> Remember, most readers of the Gnus mailing list and newsgroups are not
> good test subjects for manual readability :)

That's a fairly good point.  I think that with a bit of shepherding from
more experient documentation writers, the ``newbies'' of some particular
program should _always_ be considered a very good source of information
about what can be improved about the documentation.

It takes a lot of empathy and practice to ``get into the shoes'' of a
new user when you are already an experienced developer.  On the other
hand, if you *are* a newbie it costs nothing at all :-)

Re: What's a killed article ?

[Francis Moreau]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On Mon, 08 Dec 2008 09:46:22 -0600, Ted Zlatanov <tzz@lifelogs.com> wrote:

[...]

> new user when you are already an experienced developer.  On the other
> hand, if you *are* a newbie it costs nothing at all :-)
>

Well, it costed me way too much time to get the basic usage of Gnus
I've.

IMHO, a lots of people are likely to be discouraged when trying to use
gnus for the first time.

-- 
Francis

Re: What's a killed article ?

[Giorgos Keramidas]

On Mon, 15 Dec 2008 20:21:43 +0100, Francis Moreau <francis.moro@gmail.com> wrote:
> Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
>> On Mon, 08 Dec 2008 09:46:22 -0600, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> new user when you are already an experienced developer.  On the other
>> hand, if you *are* a newbie it costs nothing at all :-)
>
> Well, it costed me way too much time to get the basic usage of Gnus
> I've.

Hi Francis,

The full quote was:

    It takes a lot of empathy and practice to ``get into the
    shoes'' of a new user when you are already an experienced
    developer.  On the other hand, if you *are* a newbie it costs
    nothing at all :-)

I'm sorry if this wasn't very clear.  What I meant is that `newbies' are
often the best person to ask about documentation improvements.  They do
not need to spend any time or effort to get into the `newbie mindset',
because they are already there.

Experienced users tend to underestimate the effect of what they already
know to the way they read documentation.

> IMHO, a lots of people are likely to be discouraged when trying to use
> gnus for the first time.

That's true.  Now is the perfect time to help with Gnus documentation if
you want.  You still have the memories of being a new user, they are
still quite `fresh', and they stand a very good chance of being exactly
the same questions that another new user will have in a week or a month!

Do you keep an archive of your outgoing posts?  Maybe one way to help
would be to go through the questions you have posted here, and try to
extract the things that seemed difficult or confusing.  Then, we can try
to write some of these on the EmacsWiki.  If the collection of new user
questions seems to grow in the Wiki, it will be a nice project to look
for ways to integrate these into the Gnus manual.

Re: What's a killed article ?

[harven]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On Mon, 15 Dec 2008 20:21:43 +0100, Francis Moreau <francis.moro@gmail.com> wrote:
>> Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
>>> On Mon, 08 Dec 2008 09:46:22 -0600, Ted Zlatanov <tzz@lifelogs.com> wrote:
>>> new user when you are already an experienced developer.  On the other
>>> hand, if you *are* a newbie it costs nothing at all :-)
>>
>> Well, it costed me way too much time to get the basic usage of Gnus
>> I've.
>
> Hi Francis,
>
> The full quote was:
>
>     It takes a lot of empathy and practice to ``get into the
>     shoes'' of a new user when you are already an experienced
>     developer.  On the other hand, if you *are* a newbie it costs
>     nothing at all :-)
>
> I'm sorry if this wasn't very clear.  What I meant is that `newbies' are
> often the best person to ask about documentation improvements.  They do
> not need to spend any time or effort to get into the `newbie mindset',
> because they are already there.
>
> Experienced users tend to underestimate the effect of what they already
> know to the way they read documentation.
>
>> IMHO, a lots of people are likely to be discouraged when trying to use
>> gnus for the first time.
>
> That's true.  Now is the perfect time to help with Gnus documentation if
> you want.  You still have the memories of being a new user, they are
> still quite `fresh', and they stand a very good chance of being exactly
> the same questions that another new user will have in a week or a month!

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

- MAIL BACK END (info "(gnus)Comparing mail back ends") The list of
  all available mail backends should be given sooner The following
  list appears in 1.5.3 (`nnml', `nnbabyl', `nnfolder',
  `nnmbox',`nnmh', and `nnmaildir') but nnimap is also mentioned in
  3.22 and others are alluded to at 6.3.13 It would be nice if real
  life config examples were given for each of them and if their
  different features and limitations were summarized somewhere.
  For example, I tried to use nnmbox to browse some archive and got the
  following: Article mail.misc:1190 out of order. This seems specific
  to that backend, and still mysterious for me.

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

- GNUS-SECONDARY-SELECT-METHODS
  and gnus-select-method. A single select method but many secondary
  methods ? Why  differentiate ? Is it correct to put a mail group
  as the primary method ? In the following
  (setq gnus-select-method '(nntp "news.yourprovider.net"))
  "news.yourprovider.net" is the address used for news retrieval
  whereas dolk is not the address for retrieval in
  (setq gnus-secondary-select-methods
        '((nnimap "dolk" (nnimap-address "localhost")
                         (nnimap-server-port 1430))))
  Or is it ? There are reports in this newsgroup of people
  getting in trouble if "dolk" is used instead of the nnimap address.
  I ran into that problem once.

There are a number of step-by-step introductory guides around and all
of them feel necessary to give a few definitions, which are not so well
explained in the Gnus manual. So, it should not be difficult to expand
the list. BTW I think it would be better to improve the GnusTutorial
on emacswiki instead of modifying the Gnus manual.

Re: What's a killed article ?

[Giorgos Keramidas]

On Thu, 18 Dec 2008 21:00:52 +0100, harven <harven@free.fr> wrote:
> From the top of my head, some terms, either ambiguous or defined too
> late in the manual
>
> - MAIL BACK END (info "(gnus)Comparing mail back ends")
> - IDLE (info "(gnus)Daemons")
> - GNUS-SECONDARY-SELECT-METHODS

Thank you.  This is a good list of Gnus terms that may sound confusing
for new Gnus users.

> There are a number of step-by-step introductory guides around and all
> of them feel necessary to give a few definitions, which are not so
> well explained in the Gnus manual. So, it should not be difficult to
> expand the list. BTW I think it would be better to improve the
> GnusTutorial on emacswiki instead of modifying the Gnus manual.

This is a good idea too.  I will look at the tutorial on the wiki and
see how it builds a basic body of Gnus knowledge.

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

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

Re: What's a killed article ?

[Francis Moreau]

Ted Zlatanov <tzz@lifelogs.com> writes:

> 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.

I agree too.

From what I undestood, primary select method does not have qualified
group names because if you decide to change the primary method, the
groups will use this new method automatically. But since articles
numbers are not the same on different nntp servers, it's going to
break a lot of things. So changing the primary method is not
something I should do anyway.

With secondary select methods, the above doesn't seem to be possible.
-- 
Francis

Re: What's a killed article ?

[Francis Moreau]

Ted Zlatanov <tzz@lifelogs.com> writes:

[...]

> 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.

BTW, last time I tried this, I now get this message from gnus every
time I post to a news group:

   Really use this possibly unknown group: gnu.emacs.gnus? (y or n)

Do you have any idea why ?

Thanks
-- 
Francis

Re: What's a killed article ?

[Francis Moreau]

harven <harven@free.fr> writes:

[...]

> - GNUS-SECONDARY-SELECT-METHODS
>   and gnus-select-method. A single select method but many secondary
>   methods ? Why  differentiate ? Is it correct to put a mail group
>   as the primary method ?

I definitely agree.

And the sad thing is that this part is almost the first thing the user
is going to read when using gnus for the first time and is confusing.

In my understanding (mostly based on experiments) groups which belongs
to the primary server (the one given by gnu-select-method) can be
retrieved from another news server later. You just need to change the
server from gnus-select-method or by starting gnus with 'C-u M-x
gnus' (which is a bad idea actually, see later). IOW these groups
aren't stick to one server.

In contrary groups which belong to secondary servers (given by
gnus-secondary-select-methods) include the server name in their
names. So they can not be opened from different servers later.

This difference seems really useless: it gave me totaly disaster
results when I tried to swithc the primary server with 'C-u M-x gnus'
and get back to my initial server: all articles were marked as
unread. Even worse I set (display . all) on all these groups but gnus
seems to ignore it now...

Whereas the gnus doc, it says:

,----
|    A slightly different approach to foreign groups is to set the
| `gnus-secondary-select-methods' variable.  The select methods listed in
| this variable are in many ways just as native as the
| `gnus-select-method' server.  They will also be queried for active
`----

note the "in may ways just as native as the...", which sounds totaly
useless since we still don't know what the differences are.

Of course all of this is from a gnus dumb user...
-- 
Francis

Re: What's a killed article ?

[Francis Moreau]

Francis Moreau <francis.moro@gmail.com> writes:


[...]

>
> This difference seems really useless: it gave me totaly disaster
> results when I tried to swithc the primary server with 'C-u M-x gnus'
> and get back to my initial server: all articles were marked as
> unread. Even worse I set (display . all) on all these groups but gnus
> seems to ignore it now...

It's even worse: all articles are marked as _read_ and since (display
. all) has no more effect, the groups are empty...

-- 
Francis

Re: What's a killed article ?

[Francis Moreau]

Ted Zlatanov <tzz@lifelogs.com> writes:

[...]

>
> OK, we can certainly put together a glossary and use the Texinfo
> facilities to link terms to their definitions (I don't remember if
> that's specifically supported but I'm sure something can be arranged).
>
> Can you provide a list of terms you personally found challenging?

Unfortunately I haven't taken any notes on that.

But I'm probably going to read the Gnus documentation in a short time
(next time I'll try to read my emails ;) and I'll take notes about
what I find obscure and I'll give you the feedbacks.

-- 
Francis

Re: What's a killed article ?

[Ted Zlatanov]

On Mon, 15 Dec 2008 20:21:52 +0100 Francis Moreau <francis.moro@gmail.com> wrote: 

FM> But I'm probably going to read the Gnus documentation in a short time
FM> (next time I'll try to read my emails ;) and I'll take notes about
FM> what I find obscure and I'll give you the feedbacks.

Thanks.  Don't be shy about asking questions and complaining when
something doesn't work the way you expected.

Ted