tip if you have weird extra servers in the Server buffer

tip if you have weird extra servers in the Server buffer

[Matt Swift]

I was seeing weird stuff like this in my Server buffer of 0.98:

     {nnml:mail} (closed)
     {nnml:mail+nnml+mail:lppl} (opened)
     {nnml:mail+nnml+mail:mail.misc} (opened)
     {nnml:mail+nnml+mail:maybe-dupes} (opened)
     {nnml:mail+nnml+mail:tex} (opened)
     {nnml:mail+nnml+mail:texfonts} (opened)
     {nnml:mail+nnml+mail:texindex} (opened)
     {nnml:mail+nnml+mail:vfinst} (opened)
     {nnml:mail} (opened)


I tracked it down, and this is a result of having subscribed groups to
nnml+mail but with different group options.

For example:

gnus-find-method-for-group("nnml+mail:ctan-ann")
  -> (nnml "mail" (nnml-use-long-file-names t))

gnus-find-method-for-group("nnml+mail:vfinst")
  -> (nnml "mail+nnml+mail:vfinst" (nnml-address "mail") (nnml-use-long-file-names t) (nnml-get-new-mail nil))


Those two results should be parallel.  

I'm not sure exactly how I got things into this state, but I'm
guessing that I edited the virtual server and added the
nnml-get-new-mail specification after already having a couple of
groups.

To solve the problem, I edited the .newsrc.eld file by hand to make
the method for each group the same.

I'm not submitting this as a bug because I'm guessing that editing a
v. server's parameters after there are already subscribed groups in it
is one of those "features" of Gnus that I'm supposed to know better
than to ever use...  Also, I don't have the energy today to go confirm
that is the cause.  But this information may help someone seeing
similar garbage in the Server buffer.

Re: tip if you have weird extra servers in the Server buffer

[Matt Swift]

>>"M" == Matt Swift <swift@alum.mit.edu> writes:

    M> I was seeing weird stuff like this in my Server buffer of 0.98:

    M> {nnml:mail} (closed) {nnml:mail+nnml+mail:lppl} (opened)
    M> {nnml:mail+nnml+mail:mail.misc} (opened)
    M> {nnml:mail+nnml+mail:maybe-dupes} (opened)
    M> {nnml:mail+nnml+mail:tex} (opened)
    M> {nnml:mail+nnml+mail:texfonts} (opened)
    M> {nnml:mail+nnml+mail:texindex} (opened)
    M> {nnml:mail+nnml+mail:vfinst} (opened) {nnml:mail} (opened)


    M> I tracked it down, and this is a result of having subscribed
    M> groups to nnml+mail but with different group options.

This also happens when moving (`B m') any articles from an nnmh group
to an existing nnml group: you get a messsed-up version of the group
you move to in the Server buffer.  It does not occur when you create
the new nnml group during the `B m' process (neither does the new
group appear in the Group buffer in this case -- not sure if this is
right or wrong).

In this second case, restarting gnus clears up the problem, so whereas
some variables are getting corrupted, .newsrc.eld is not.

More on this as I track it down.

Re: tip if you have weird extra servers in the Server buffer

[Simon Josefsson]

Matt Swift <swift@alum.mit.edu> writes:

> I'm not sure exactly how I got things into this state, but I'm
> guessing that I edited the virtual server and added the
> nnml-get-new-mail specification after already having a couple of
> groups.

Yes, that's what causing it.

> To solve the problem, I edited the .newsrc.eld file by hand to make
> the method for each group the same.

You can use `G e' on the groups.

> I'm not submitting this as a bug because I'm guessing that editing a
> v. server's parameters after there are already subscribed groups in it
> is one of those "features" of Gnus that I'm supposed to know better
> than to ever use...  Also, I don't have the energy today to go confirm
> that is the cause.  But this information may help someone seeing
> similar garbage in the Server buffer.

Latest pGnus doesn't store the select method in groups [when creating
new groups, old groups not affected], it simply store a string, such
as "nnfolder:archive", which is derefenced to the actual select method
(from `gnus-secondary-select-methods' or similar) when needed.

Hopefully this should get rid of some of the bogus server problems
several nnimap users have been seeing...

group and method variables still a deep mystery to me

[Matt Swift]

>> Simon Josefsson wrote:

    S> Latest pGnus doesn't store the select method in groups [when
    S> creating new groups, old groups not affected], it simply store
    S> a string, such as "nnfolder:archive", which is derefenced to
    S> the actual select method (from `gnus-secondary-select-methods'
    S> or similar) when needed.

I am using today's CVS of pgnus.  I manually expunged all mention of
all nnmh servers and groups from my .newsrc.eld and restarted gnus.
`gnus-secondary-select-methods' is nil.  `gnus-select-method' is an
nntp server. I entered the server buffer and added a server nnmh
called "mhmail".  i edited it to give it an nnmh-directory.  I entered
it (from the server buffer still).  I subscribed one of the groups.  I
quit to the Groups buffer and entered the group to see if it all
worked OK, which it did.  I quit gnus.  I examined .newsrc.eld:

gnus-newsrc-alist has a new item:
("nnmh+mhmail:acevedo" 3 nil nil (nnmh "mhmail" (nnmh-directory "~/MHMail")))

gnus-server-alist now has a new item:
("mhmail" nnmh "mhmail" (nnmh-directory "~/MHMail"))

You imply above that a major change has been introduced in the way
group data is stored, but the behavior I describe seems identical to
the old behavior, so I don't understand what it is that you say has
changed.  Can you describe the change in more detail?

In general, I would find it very useful if someone knowledgeable would
offer a discussion in as much detail as possible of the variables
`gnus-server-alist', `gnus-secondary-select-methods',
`gnus-opened-servers', `gnus-newsrc-alist', their associated hashes,
the API functions to manipulate them, how they are set up when gnus
starts, how they are consulted to set up the Group and Server buffers,
how they are changed when new groups and servers are added and killed
in the various ways this can be done, how they are consulted when
group names are called for in functions like moving and copying
articles from one group to another, and the way(s) this state is saved
between gnus sessions.

That's a tall order, I know, but it would take me several full days, I
imagine, to reverse-engineer even a tenuous understanding from the
sources.  This hard-won information could probably be summarized in
only a page or two of notes.

    S> Hopefully this should get rid of some of the bogus server
    S> problems several nnimap users have been seeing...

When I notice that even you have to resort to `hope' when addressing
current problems with these complex data structures, it seems to me
that time spent in preparing an overview at at this level might help
more than just me.

I am continually confronted by puzzling Gnus behavior, most of it to
do with the group and server data structures, and much that would be
very easy to track down if only I could get a handle on the basics
(e.g., problems with use-long-file-names).  The major barrier for me
to analyzing, reporting, and fixing such problems is the time it takes
me to reverse-engineer what the relevant core variables and data
structures are supposed to be doing.

What, for example, are the 5 elements of each item in
`gnus-newsrc-alist' and the 4 elements in `gnus-server-alist'?

Re: group and method variables still a deep mystery to me

[Simon Josefsson]

Matt Swift <swift@alum.mit.edu> writes:

>     S> Latest pGnus doesn't store the select method in groups [when
>     S> creating new groups, old groups not affected], it simply store
>     S> a string, such as "nnfolder:archive", which is derefenced to
>     S> the actual select method (from `gnus-secondary-select-methods'
>     S> or similar) when needed.
> 
> I am using today's CVS of pgnus.  I manually expunged all mention of
> all nnmh servers and groups from my .newsrc.eld and restarted gnus.
> `gnus-secondary-select-methods' is nil.  `gnus-select-method' is an
> nntp server. I entered the server buffer and added a server nnmh
> called "mhmail".  i edited it to give it an nnmh-directory.  I entered
> it (from the server buffer still).  I subscribed one of the groups.  I
> quit to the Groups buffer and entered the group to see if it all
> worked OK, which it did.  I quit gnus.  I examined .newsrc.eld:
> 
> gnus-newsrc-alist has a new item:
> ("nnmh+mhmail:acevedo" 3 nil nil (nnmh "mhmail" (nnmh-directory "~/MHMail")))
> 
> gnus-server-alist now has a new item:
> ("mhmail" nnmh "mhmail" (nnmh-directory "~/MHMail"))
> 
> You imply above that a major change has been introduced in the way
> group data is stored, but the behavior I describe seems identical to
> the old behavior, so I don't understand what it is that you say has
> changed.  Can you describe the change in more detail?

My (not very major) change only handle the case where the server is
primary or secondary (ie the "from gnus-secondary-select-methods or
similar" part above), this is not the case for you, and the old
behaviour is still used -- and the old bug which my patch try to solve
is still around.

> When I notice that even you have to resort to `hope' when addressing
> current problems with these complex data structures, it seems to me
> that time spent in preparing an overview at at this level might help
> more than just me.

Oh yes, a document describing all this would be immensely useful.

OTOH perhaps this can also be simplified by removing the low-level
distinction between primary, secondary, foreign etc servers and let
thoose be user-interface selections -- I don't see the need for it to
be anything else. Then there probably wouldn't be a great need for
such a document. Doing that wouldn't be easy though.

> What, for example, are the 5 elements of each item in
> `gnus-newsrc-alist'

>From "Group Info" subsection of the manual:

***
     ("nnml:my.mail" 3 ((1 . 5) 9 (20 . 55))
                     ((tick (15 . 19)) (replied 3 6 (19 . 3)))
                     (nnml "")
                     ((auto-expire . t) (to-address . "ding@gnus.org")))

   The first element is the "group name"--as Gnus knows the group,
anyway.  The second element is the "subscription level", which normally
is a small integer.  (It can also be the "rank", which is a cons cell
where the `car' is the level and the `cdr' is the score.)  The third
element is a list of ranges of read articles.  The fourth element is a
list of lists of article marks of various kinds.  The fifth element is
the select method (or virtual server, if you like).  The sixth element
is a list of "group parameters", which is what this section is about.
***

>  and the 4 elements in `gnus-server-alist'?

If you `cdr' each element in that list you get a select method, so
it's the select method's parameters.