Pterodactyl Gnus v0.98 is released

Pterodactyl Gnus v0.98 is released

[Lars Magne Ingebrigtsen]

This release syncs up to the CVS, basically.

Get it from <URL:http://quimby.gnus.org/gnus/dist/pgnus.tar.gz>
or "/ftp@quimby.gnus.org:/pub/gnus/".  The patch is available as
<URL:ftp://quimby.gnus.org/pub/gnus/ding-patches/pgnus-0.97-0.98.diff.gz>.

ChangeLog since last release:

Fri Nov  5 19:10:02 1999  Lars Magne Ingebrigtsen  <larsi@menja.ifi.uio.no>

	* gnus.el: Pterodactyl Gnus v0.98 is released.

1999-11-05 01:27:49  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* gnus-agent.el (gnus-agent-expire): Remove bad line in NOV.

1999-11-04 22:20:35  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mml.el (mml-generate-mime-1): Read attached binary file in
 	binary mode.

1999-11-03 16:08:56  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* gnus-sum.el (gnus-summary-toggle-header): Fix arg bug.

1999-11-03 15:27:38  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mailcap.el (mailcap-viewer-lessp): Fix bug.

1999-11-02 17:28:33  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* gnus-sum.el (gnus-summary-search-article): Fix loop search bug.

1999-10-31 21:24:59  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* gnus-art.el (gnus-article-mime-match-handle-first): New function.
	(gnus-article-mime-match-handle-function): New variable.
	(gnus-article-view-part): Make `b' customizable.

1999-10-29 14:30:07  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* gnus-sum.el (gnus-article-get-xrefs): Test eobp.

1999-09-27  Hrvoje Niksic  <hniksic@srce.hr>

	* mm-decode.el (mm-attachment-override-types): Exclude text/plain.

1999-10-26 23:27:44  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mm-decode.el (mm-dissect-buffer): CTE may come without CTL.

1999-10-26 21:44:05  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* gnus-srvr.el (gnus-browse-foreign-server): Use
 	`buffer-substring' instead of `read'.

1999-10-23  Simon Josefsson  <jas@pdc.kth.se>

	* nnimap.el, imap.el, rfc2104.el: New files.

	* gnus.el (gnus-valid-select-methods): Add nnimap.

	* gnus-group.el (gnus-group-group-map): Add
	gnus-group-nnimap-edit-acl, gnus-group-nnimap-expunge.
	(gnus-group-nnimap-expunge): New function.
	(gnus-group-nnimap-edit-acl): New function.

	* gnus-agent.el (gnus-agent-group-mode-map): Add
	gnus-agent-synchronize.
	(gnus-agent-synchronize): New function.
	(gnus-agent-fetch-group-1): Check if server is open.

	* nnagent.el (nnagent-request-set-mark): Save marks.

	* mail-source.el (mail-source-keyword-map): New imap mail-source.
	(mail-source-fetcher-alist): Map to imap fetcher function.
	(mail-source-fetch-imap): New function.

	* gnus-art.el (article-hide-pgp): Hide all headers, not just
	Hash:.

1999-10-22 11:03:00  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* gnus-topic.el (gnus-topic-sort-topics-1): New function.
	(gnus-topic-sort-topics): New function.
	(gnus-topic-make-menu-bar): Add sort-topics.
	(gnus-topic-move): New function.
	(gnus-topic-move-group): Move the topic if no group selected.

1999-10-13 21:31:50  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* gnus-art.el (gnus-article-setup-buffer): Fix buffer leak.

1999-10-13 12:52:18  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mm-view.el (mm-inline-message): Fix leaving group bug.

1999-10-07 17:59:49  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* gnus-msg.el (gnus-post-method): Use normal method if current is
	not available.

1999-10-07 17:09:34  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* nnmail.el (nnmail-insert-xref): Dealing with empty articles.
	(nnmail-insert-lines): Ditto.

1999-10-07  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* nnfolder.el (nnfolder-insert-newsgroup-line): Insert a blank
	line.

	* message.el (message-unsent-separator): One more separator.

1999-10-06  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* nnfolder.el (nnfolder-request-move-article): For empty article,
	search till (point-max).
	(nnfolder-retrieve-headers): Ditto.
	(nnfolder-request-accept-article): Ditto.
	(nnfolder-save-mail): Ditto.
	(nnfolder-insert-newsgroup-line): Ditto.

1999-10-05  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* qp.el (quoted-printable-encode-region): Check eobp.

1999-10-03  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* nntp.el (nntp-retrieve-headers-with-xover): Fix hanging problem.

1999-10-02  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* nntp.el (nntp-send-xover-command): Wait for nothing if not
	wait-for-reply.

1999-09-29  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mm-uu.el (mm-uu-forward-begin-line): Change the regexp.
	(mm-uu-forward-end-line): Ditto. 

1999-09-29  Didier Verna  <verna@inf.enst.fr>

	* binhex.el (binhex-decode-region): don't consider the value of
	`enable-multibyte-characters' in XEmacs.

	* gnus-start.el (gnus-read-descriptions-file): ditto.

	* mm-util.el (mm-multibyte-p): ditto.
	(mm-with-unibyte-buffer): ditto.
	(mm-find-charset-region): use `mm-multibyte-p'.

	* mm-bodies.el (mm-decode-body): ditto.
	(mm-decode-string): ditto.

	* lpath.el ((string-match "XEmacs" emacs-version)): Don't define
	`enable-multibyte-characters' in XEmacs.

1999-09-29  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mm-util.el (mm-binary-coding-system): Try binary first.

1999-09-14  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* rfc1843.el (rfc1843-decode-article-body): Don't decode twice.

1999-09-10  Shenghuo ZHU  <zsh@cs.rochester.edu>
	
	* gnus-art.el (article-make-date-line): Add time-zone in iso8601
	format.
	(article-date-ut): Find correct insert position.
	
1999-09-03  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mm-uu.el (mm-uu-dissect): Do not dissect quoted-printable
	forwarded message.

1999-09-27 20:33:41  Lars Magne Ingebrigtsen  <larsi@gnus.org>

	* gnus-topic.el (gnus-topic-find-groups): Work for unactivated
	groups. 

	* message.el (message-resend): Use message mode when prompting. 

	* gnus-art.el (article-hide-headers): Mark wash.
	(article-emphasize): Ditto.

1999-09-27 19:52:14  Vladimir Volovich  <vvv@vvv.vsu.ru>

	* message.el (message-newline-and-reformat): Work for SC. 

1999-09-27 19:38:33  Lars Magne Ingebrigtsen  <larsi@gnus.org>

	* gnus-msg.el (gnus-group-posting-charset-alist): 2047 in de.*.

	* gnus-sum.el (gnus-newsgroup-ignored-charsets): Add x-unknown. 

>>>>>>> 5.100


-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.98 is released

[Per Abrahamsen]

Now lets get a real release.  Please.  It is getting really difficult
to justify advising newbies against pGnus, especially if they want to
use it for mail.

It probably won't be in time for Emacs 20.5, although that would have
been nice.

Re: Pterodactyl Gnus v0.98 is released

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Now lets get a real release.  Please.

Yes.  But I kinda feel I should go through the bug backlog (that is,
the remaining bits that Shenghou haven't already dealt with :-))
first, though.

So 0.99 first, and then onto 5.8.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Pterodactyl Gnus v0.98 is released

[Matt Swift]

>>"P" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

    P> Now lets get a real release.  Please.  It is getting really
    P> difficult to justify advising newbies against pGnus, especially
    P> if they want to use it for mail.

Eh?  pGnus 0.97 still can't keep track of my subscribed groups
properly, and working in the server buffer gives pretty random
results, certainly not what's documented.  I submitted bug reports on
this stuff (against 0.96) in August and never heard back.  If you guys
are serious about pGnus 0.98 being ready for prime time, then either
we are not in the same universe as me or I've got a very thrashed
..newsrc or some other kind of legacy problems from prior 0.9x problems
(I don't know where they could lurk besides .newsrc*).  My
config/customatizations have always been pretty run-of-the-mill, not
the simplest, but nothing fancy.  Short of deleting my .newsrc and
starting from scratch, is there anything you can recommend?

Re: Pterodactyl Gnus v0.98 is released

[Kai Großjohann]

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

> Eh?  pGnus 0.97 still can't keep track of my subscribed groups
> properly,

I don't remember that Gnus was subscribing or unsubscribing any group
without me explicitly saying so.  Not in the last year or two.  Hm.
Strange. 

> and working in the server buffer gives pretty random results,
> certainly not what's documented.

Hm.  I don't use the server buffer (much), so I don't know.

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: Pterodactyl Gnus v0.98 is released

[Matt Swift]

>>"K" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    K> Matt Swift <swift@alum.mit.edu> writes:
    >> Eh?  pGnus 0.97 still can't keep track of my subscribed groups
    >> properly,

    K> I don't remember that Gnus was subscribing or unsubscribing any
    K> group without me explicitly saying so.  Not in the last year or
    K> two.  Hm.  Strange.

For example:

I've got a lot of groups that I once subscribed to, and that I can
verify are mentioned in an apparently proper way in my .newsrc*.eld
file, that will never *ever* show up in the group buffer, no matter
what commands I try, unless it's `A A' (or whatever it is to download
and list the entire active file).  In the latter case all groups show
up as "killed".  If you try to subscribe to one of those groups lost
in the void, you get told that you are already a subscriber, so you
can't get these groups out of the void.  They are all in .newsrc*.eld
as level 5 or 6 (I think), but as I read the documentation, no matter
what my various `gnus-activate-level' `gnus-subscribe-level' type of
variables might be set to (i'm using reasonable though not default
values), I should get them all in the group buffer by typing '9 L',
and I don't.

Working with the server buffer, you get the same kind of confusion
over what groups are actually there, what are subscribed, and what
appears on your screen, with what designation, what manipulation you
are permitted to perform on them, etc.

Re: Pterodactyl Gnus v0.98 is released

[Simon Josefsson]

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

> Working with the server buffer, you get the same kind of confusion
> over what groups are actually there, what are subscribed, and what
> appears on your screen, with what designation, what manipulation you
> are permitted to perform on them, etc.

FWIW, in the server buffer all groups are 'K'. It doesn't mean
"killed", "unsubscribed" or something like that. It's simply hard
coded to say 'K' there.

Re: Pterodactyl Gnus v0.98 is released

[Kai Großjohann]

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

> I've got a lot of groups that I once subscribed to, and that I can
> verify are mentioned in an apparently proper way in my .newsrc*.eld
> file, that will never *ever* show up in the group buffer, no matter
> what commands I try, unless it's `A A' (or whatever it is to download
> and list the entire active file).

Amazing.  A group that's hiding from you.  Whee.

Lessee.  Do you use topics?  Does the group appear if you toggle
topics?  (I'm thinking maybe the group does not belong to any topic,
or it belongs to a hidden topic.)

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: Pterodactyl Gnus v0.98 is released

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Amazing.  A group that's hiding from you.  Whee.
> 
> Lessee.  Do you use topics?  Does the group appear if you toggle
> topics?  (I'm thinking maybe the group does not belong to any topic,
> or it belongs to a hidden topic.)

I have had a similar problem.  

        1. I find new newsgroups with `F'.
        2. I list them with `A z'.
        3. I subscribe them with `u'.
        4. I move them to the appropriate topic with `T m'.
        5. Everything works fine for a while.
        6. I restart gnus and the groups are gone.
        7. I can find them with `j newsgroup' or by leaving topics mode.
        8. The problem is gone, and I can't reproduce it, so I don't
           write a bug report. :-(

Because of the time between 1 and 8 I'm never completely certain what
happened or if I did something to provoke the problem.  So the
sequence above should be taken as my best bet.

Re: Pterodactyl Gnus v0.98 is released

[Matt Swift]

>>"K" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    K> Matt Swift <swift@alum.mit.edu> writes:
    >> I've got a lot of groups that I once subscribed to, and that I
    >> can verify are mentioned in an apparently proper way in my
    >> .newsrc*.eld file, that will never *ever* show up in the group
    >> buffer, no matter what commands I try, unless it's `A A' (or
    >> whatever it is to download and list the entire active file).

    K> Amazing.  A group that's hiding from you.  Whee.

    K> Lessee.  Do you use topics?  Does the group appear if you
    K> toggle topics?  (I'm thinking maybe the group does not belong
    K> to any topic, or it belongs to a hidden topic.)

No, I'm not using topics.  

I just recently deleted all my .newsrc files and started from scratch
with 0.98, and the same problem reappeared: I subscribed a bunch of
nntp groups from the primary server (level 3).  I changed one each to
level 4, 5, 6, 7, 8, and 9.  So far so good, but next session, the
groups on levels 5, 6, and 7 were lost in the void, though still in my
..newsrc file.  levels 3, 4, 8 (zombie) group, and 9 (killed), behaved
properly.  I think also fine for levels 1 and 2, but didn't check
explicitly this time.

This is not a slight or subtle bug!

Will submit a proper bug report right now; it's going to be
essentially the same as one I submitted 3 months ago aginst 0.95 or
whatever.

Re: Pterodactyl Gnus v0.98 is released

[Jody M. Klymak]

Matt,

Have you checked the values for the gnus-level-* variables?  Gnus sets
certain default levels as beyond the ken.  For instance,
gnus-level-default-subscribed = 3.

I'm not so familair with how all this works, but I'm under the
impression that this means groups below 3 are not regarded as
suscribed.  Though I'm sure they are not lost in the void either -
have you tried hitting "L" in the group buffer?

Cheers,  Jody
 
>>>>> "MS" == Matt Swift <swift@alum.mit.edu> writes:

    >>> "K" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
    >>> writes:
    K> Matt Swift <swift@alum.mit.edu> writes:
    >>> I've got a lot of groups that I once subscribed to, and that I
    >>> can verify are mentioned in an apparently proper way in my
    >>> .newsrc*.eld file, that will never *ever* show up in the group
    >>> buffer, no matter what commands I try, unless it's `A A' (or
    >>> whatever it is to download and list the entire active file).

    K> Amazing.  A group that's hiding from you.  Whee.

    K> Lessee.  Do you use topics?  Does the group appear if you
    K> toggle topics?  (I'm thinking maybe the group does not belong
    K> to any topic, or it belongs to a hidden topic.)

    MS> No, I'm not using topics.

    MS> I just recently deleted all my .newsrc files and started from
    MS> scratch with 0.98, and the same problem reappeared: I
    MS> subscribed a bunch of nntp groups from the primary server
    MS> (level 3).  I changed one each to level 4, 5, 6, 7, 8, and 9.
    MS> So far so good, but next session, the groups on levels 5, 6,
    MS> and 7 were lost in the void, though still in my ..newsrc file.
    MS> levels 3, 4, 8 (zombie) group, and 9 (killed), behaved
    MS> properly.  I think also fine for levels 1 and 2, but didn't
    MS> check explicitly this time.

    MS> This is not a slight or subtle bug!

    MS> Will submit a proper bug report right now; it's going to be
    MS> essentially the same as one I submitted 3 months ago aginst
    MS> 0.95 or whatever.

-- 
Jody Klymak                         APL/School of Oceanography,
Doctoral Candidate                  University of Washington
mailto:jklymak@apl.washington.edu   (206)-685-9080
http://www.ocean.washington.edu/people/grads/jklymak/

Re: Pterodactyl Gnus v0.98 is released

[Matt Swift]

>>"JMK" == Jody M Klymak <jklymak@apl.washington.edu> writes:

    JMK> Matt,

    JMK> Have you checked the values for the gnus-level-* variables?

Well, those variables are surely involved.  At a guess, it's not
showing me anything between `gnus-activate-level' and
`gnus-level-zombie', but I've got sane values, the way I read the dox.
If my guess is right, anyone using default values would lose all
groups of level 7 into the void.

The way I read the dox, the command `<n> L' where <n> is
gnus-level-killed should put every group subscribed at level L where 1
<= L < gnus-level-killed in the Group buffer, regardless of the other
variables' values.

gnus-level-default-subscribed     3
gnus-activate-level               4
gnus-group-default-list-level     5
gnus-level-subscribed             5
          -default-unsubscribed   6
                  -unsubscribed   7
          -zombie                 8
          -killed                 9

Re: Pterodactyl Gnus v0.98 is released

[Jody M. Klymak]

Hi Matt,

>>>>> "MS" == Matt Swift <swift@alum.mit.edu> writes:
    JMK> Have you checked the values for the gnus-level-* variables?

    MS> gnus-level-default-subscribed 3 
    MS> gnus-activate-level 4
    MS> gnus-group-default-list-level 5 
    MS> gnus-level-subscribed 5
    MS>           -default-unsubscribed 6 
    MS>                   -unsubscribed 7 
    MS>                   -zombie 8 
    MS>                    -killed 9

I have the same values except my gnus-activate-level is 6.  But it
sounds like maybe you understand what is going on better than I do.
Just trying to give you a base point to compare with.

Cheers,  Jody

-- 
Jody Klymak                         APL/School of Oceanography,
Doctoral Candidate                  University of Washington
mailto:jklymak@apl.washington.edu   (206)-685-9080
http://www.ocean.washington.edu/people/grads/jklymak/

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

>>"JMK" == Jody M Klymak <jklymak@apl.washington.edu> writes:

    JMK> Hi Matt,

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

    JMK> Have you checked the values for the gnus-level-* variables?

    MS> gnus-level-default-subscribed 3 
    MS> gnus-activate-level 4
    MS> gnus-group-default-list-level 5 
    MS> gnus-level-subscribed 5
    MS> -default-unsubscribed 6 
    MS> -unsubscribed 7 
    MS> -zombie 8 
    MS> -killed 9

    JMK> I have the same values except my gnus-activate-level is 6.  But it
    JMK> sounds like maybe you understand what is going on better than I do.
    JMK> Just trying to give you a base point to compare with.

You inspired me to experiment.

Following up this bug report:

  To: bugs@gnus.org (The Gnus Bugfixing Girls + Boys)
  Subject: groups in levels 5-7 won't appear in groups buffer
  From: Matt Swift <swift@alum.mit.edu>
  Date: 08 Nov 1999 13:44:03 -0500
  Message-ID: <m2wvrsombw.fsf@aleph.swift.xxx>

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

    M> I just recently deleted all my .newsrc files and started from
    M> scratch with 0.98, and a problem I've had since at least 0.96
    M> persisted: I subscribed a bunch of nntp groups from the primary
    M> server (level 3).  I changed one each to level 4, 5, 6, 7, 8,
    M> and 9.  So far so good, but next session, the groups on levels
    M> [ etc ...] 


I experimented with changing the value of `gnus-activate-level' in
custom-file and restarting Emacs.  I cannot see groups with level L
s.t. gnus-activate-level < L < gnus-level-zombie

(If right, this would mean that anyone with standard values (i.e., 6
and 8) is going to loose groups with level 7.  If you want to try, set
one group to level 7 (`S l 7').  Write down the name of it.  Restart
Emacs/Gnus, press `9 L' in the Group buffer.  I bet you won't see your
group.  Resubscribe to it by typing `j' and your group name.  Change
it's level back to something other than 7.)

But there is another catch.  From the beginning I've had
gnus-level-zombie at 8.  I changed it to 7 in the custom-file and
restarted Emacs.  I was thinking this might let me see level 7 (or
7-8) groups as zombie groups, like I'd seen my level 8 zombie group
before. This had absolutely no effect, as far as I can tell, however.
I quit Emacs and looked at .newsrc.eld.  The statement (setq
gnus-zombie-list...) still contained my old level-8 group, and the
level 7 group was still listed as before, i.e., with the subscribed
groups.

So it seems like there's a bug with changing gnus-level-zombie.

Also, it's unclear what is supposed to happen when you have the
situation gnus-level-zombie + N = gnus-level-killed where N > 1.  (In
my case, gnus-level-zombie = 7 and gnus-level-killed = 9).  The dox
for gnus-level-zombie say "Groups with this level are zombie groups".
It does *not* say "Groups with this level or greater and level less
than gnus-level-killed are zombie groups".  So what happens to groups
at level 8 in this case?  Are they zombies?  Killed?  They are between
the living dead and the dead, So maybe the 'dying living dead'?

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Lars Magne Ingebrigtsen]

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

> So it seems like there's a bug with changing gnus-level-zombie.

If you're changing the level variables, you're headed for a world of
pain.

I've never attempted to do so, and there's probably lots of obscure
dependencies you're going to run into.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

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

    L> Matt Swift <swift@alum.mit.edu> writes:
    >> So it seems like there's a bug with changing gnus-level-zombie.

    L> If you're changing the level variables, you're headed for a
    L> world of pain.

    L> I've never attempted to do so, and there's probably lots of
    L> obscure dependencies you're going to run into.

Warning noted.

But you do agree that in an ideal Gnus, one *should* be able to change
them, right?  (Otherwise, why are they defined as user variables?)

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Lars Magne Ingebrigtsen]

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

> But you do agree that in an ideal Gnus, one *should* be able to change
> them, right? 

Yes.  So if you want to chase down all the problems in this area,
please do.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Kai Großjohann]

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

> Yes.  So if you want to chase down all the problems in this area,
> please do.  :-)

Well, I haven't changed any levels except for gnus-activate-level, and
I see a problem with disappearing groups...  I wonder how I could help
to debug this?

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

>>"K" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    K> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
    >> Yes.  So if you want to chase down all the problems in this
    >> area, please do.  :-)

    K> Well, I haven't changed any levels except for
    K> gnus-activate-level, and I see a problem with disappearing
    K> groups...  I wonder how I could help to debug this?

Did you try my fix to `gnus-group-prepare-flat'?  I haven't had any
feedback on it.

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Well, I haven't changed any levels except for gnus-activate-level, and
> I see a problem with disappearing groups...  I wonder how I could help
> to debug this?

It's `gnus-level-unsubscribed' and friends that are the problem; not
the, er, more higher-level variables.  I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Per Abrahamsen]

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

> If you're changing the level variables, you're headed for a world of
> pain.

In that case, it would probably be a good idea to change them from
defcustoms to defconsts.

Do you want a patch? ;-)

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> In that case, it would probably be a good idea to change them from
> defcustoms to defconsts.
> 
> Do you want a patch? ;-)

Yes, please.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Per Abrahamsen]

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

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> > In that case, it would probably be a good idea to change them from
> > defcustoms to defconsts.
> > 
> > Do you want a patch? ;-)
> 
> Yes, please.  :-)

1999-11-12  Per Abrahamsen  <abraham@dina.kvl.dk>

	* gnus-start.el (gnus-level-subscribed, gnus-level-unsubscribed,
	gnus-level-zombie, gnus-level-killed): Changed from `defcustom' to
	`defconst'.

Index: gnus-start.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-start.el,v
retrieving revision 5.37
diff -c -r5.37 gnus-start.el
*** gnus-start.el	1999/11/12 07:03:48	5.37
--- gnus-start.el	1999/11/12 19:26:33
***************
*** 141,167 ****
  		 (const some)
  		 (const t)))
  
! (defcustom gnus-level-subscribed 5
!   "*Groups with levels less than or equal to this variable are subscribed."
!   :group 'gnus-group-levels
!   :type 'integer)
  
! (defcustom gnus-level-unsubscribed 7
!   "*Groups with levels less than or equal to this variable are unsubscribed.
  Groups with levels less than `gnus-level-subscribed', which should be
! less than this variable, are subscribed."
!   :group 'gnus-group-levels
!   :type 'integer)
  
! (defcustom gnus-level-zombie 8
!   "*Groups with this level are zombie groups."
!   :group 'gnus-group-levels
!   :type 'integer)
  
! (defcustom gnus-level-killed 9
!   "*Groups with this level are killed."
!   :group 'gnus-group-levels
!   :type 'integer)
  
  (defcustom gnus-level-default-subscribed 3
    "*New subscribed groups will be subscribed at this level."
--- 141,159 ----
  		 (const some)
  		 (const t)))
  
! (defconst gnus-level-subscribed 5
!   "Groups with levels less than or equal to this variable are subscribed.")
  
! (defconst gnus-level-unsubscribed 7
!   "Groups with levels less than or equal to this variable are unsubscribed.
  Groups with levels less than `gnus-level-subscribed', which should be
! less than this variable, are subscribed.")
  
! (defconst gnus-level-zombie 8
!   "Groups with this level are zombie groups.")
  
! (defconst gnus-level-killed 9
!   "Groups with this level are killed.")
  
  (defcustom gnus-level-default-subscribed 3
    "*New subscribed groups will be subscribed at this level."

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

>>"P" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

    P> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
    >> Per Abrahamsen <abraham@dina.kvl.dk> writes:
    >> 
    >> > In that case, it would probably be a good idea to change them
    >> from > defcustoms to defconsts.  > > Do you want a patch? ;-)
    >> 
    >> Yes, please.  :-)

    P> 1999-11-12 Per Abrahamsen <abraham@dina.kvl.dk>

    P> * gnus-start.el (gnus-level-subscribed,
    P> gnus-level-unsubscribed, gnus-level-zombie, gnus-level-killed):
    P> Changed from `defcustom' to `defconst'.

What happens to existing customized settings in the `custom-file' when
a change like this occurs?  Do they have to be deleted by hand?
Should they?

Re: groups in levels 5-7 won't appear in groups buffer (was: Pterodactyl Gnus v0.98 is released)

[Per Abrahamsen]

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

> >>"P" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
>     P> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>     >> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>     >> 
>     >> > In that case, it would probably be a good idea to change them
>     >> from > defcustoms to defconsts.  > > Do you want a patch? ;-)
>     >> 
>     >> Yes, please.  :-)
> 
>     P> 1999-11-12 Per Abrahamsen <abraham@dina.kvl.dk>
> 
>     P> * gnus-start.el (gnus-level-subscribed,
>     P> gnus-level-unsubscribed, gnus-level-zombie, gnus-level-killed):
>     P> Changed from `defcustom' to `defconst'.
> 
> What happens to existing customized settings in the `custom-file' when
> a change like this occurs?  Do they have to be deleted by hand?
> Should they?

I think the smartest thing is to delete them by hand.  As far as I can
figure out, the value will be ignored.

Re: Pterodactyl Gnus v0.98 is released

[Lee Willis]

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

> Well, those variables are surely involved.  At a guess, it's not
> showing me anything between `gnus-activate-level' and
> `gnus-level-zombie', but I've got sane values, the way I read the dox.
> If my guess is right, anyone using default values would lose all
> groups of level 7 into the void.

Yes, I'll explain way in a second ...

> The way I read the dox, the command `<n> L' where <n> is
> gnus-level-killed should put every group subscribed at level L where 1
> <= L < gnus-level-killed in the Group buffer, regardless of the other
> variables' values.

Yes that's correct, the important bit is the "every group *subscribed*"
bit.

>                   -unsubscribed   7

You put a group into level 7, therefore unsubscribing it. pGnus is
correct in not showing it when you do a 9L. I did this here and sure
enough the group disappeared. However j'ing to it and setting its level
back to 1 (I use pgnus for mail only ...) all is fine and dandy again.

Hope this helps

Lee
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: Pterodactyl Gnus v0.98 is released

[Matt Swift]

>>"L" == Lee Willis <lee@gbdirect.co.uk> writes:

    L> Matt Swift <swift@alum.mit.edu> writes:
    >> Well, those variables are surely involved.  At a guess, it's
    >> not showing me anything between `gnus-activate-level' and
    >> `gnus-level-zombie', but I've got sane values, the way I read
    >> the dox.  If my guess is right, anyone using default values
    >> would lose all groups of level 7 into the void.

    L> Yes, I'll explain way in a second ...

    >> The way I read the dox, the command `<n> L' where <n> is
    >> gnus-level-killed should put every group subscribed at level L
    >> where 1 <= L < gnus-level-killed in the Group buffer,
    >> regardless of the other variables' values.

    L> Yes that's correct, the important bit is the "every group
    L> *subscribed*" bit.

    >> -unsubscribed 7

    L> You put a group into level 7, therefore unsubscribing it. pGnus
    L> is correct in not showing it when you do a 9L. I did this here
    L> and sure enough the group disappeared. However j'ing to it and
    L> setting its level back to 1 (I use pgnus for mail only ...) all
    L> is fine and dandy again.

    L> Hope this helps

Not really.  You are quoting me, not the documentation, when you quote
"the important bit".  Forget the word "subscribe", it's confusing, as
it means a binary thing in most newsreaders, but has gradations, aka
levels in Gnus.  The command `9 L' means "list all groups that Gnus
knows about with group levels 9 or lower".  This includes groups of
level 7.  

By your reasoning, `9 L' should not show you groups of level 8 (they
are "unsubscribed"), but it does.

Here's the real documentation for L in the summary buffer:

L runs the command gnus-group-list-all-groups
   which is an interactive compiled Lisp function in `gnus-group'.
(gnus-group-list-all-groups &optional ARG)

List all newsgroups with level ARG or lower.
Default is gnus-level-unsubscribed, which lists all subscribed and most
unsubscribed groups.

Re: Pterodactyl Gnus v0.98 is released

[Matt Swift]

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

>>"P" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
    P> Now lets get a real release.  Please.  It is getting really
    P> difficult to justify advising newbies against pGnus, especially
    P> if they want to use it for mail.

    M> Eh?  pGnus 0.97 still can't keep track of my subscribed groups
    M> properly, and working in the server buffer gives pretty random
    M> results, certainly not what's documented.  I submitted bug
    M> reports on this stuff (against 0.96) in August and never heard
    M> back.  If you guys are serious about pGnus 0.98 being ready for
    M> prime time, then either we are not in the same universe as me
    M> or I've got a very thrashed ..newsrc or some other kind of
    M> legacy problems from prior 0.9x problems (I don't know where
    M> they could lurk besides .newsrc*).  My config/customatizations
    M> have always been pretty run-of-the-mill, not the simplest, but
    M> nothing fancy.  Short of deleting my .newsrc and starting from
    M> scratch, is there anything you can recommend?


Well, I deleted my .newsrc files and started fresh with 0.98.  I
started going through the list of bugs (all of them quite significant
IMO) that I submitted against 0.96 in August, and so far 3 of 3 are
still in 0.98, so I'm submitting them again as I re-confirm them with
0.98.  I guess it's my bad luck that I like to use all the broken
features....

Re: Pterodactyl Gnus v0.98 is released

[Thomas Skogestad]

* Per Abrahamsen

| Now lets get a real release.  Please.  It is getting really difficult to
| justify advising newbies against pGnus, especially if they want to use
| it for mail.

But since 0.86 posting styles seems to behave a bit oddly. 

If I try send a mail from a newsgroup, the mail inherits the settings for
that group, even though I have specified separate settings for mail. This
does not happen in 0.85.

So I've just copied the relevant posting styles code from gnus-msg.el in
0.85 to the same file in 0.98. (I tried copying the code to a separate
file, but I got all sorts of error messages, and it just a lot less of
hassle replacing the code in gnus-msg.el)

-- 
thomas.skogestad@jusstud.uio.no
http://cgi.mercurycenter.com/premium/comics/10_13/dilbert.gif
http://buzz.bazooka.se/buzz/braz/ * http://www.istanbul.tc/mahir/
http://www.foxmovies.com/fightclub/flightcard_sm.jpg (minor spoiler)

Re: Pterodactyl Gnus v0.98 is released

[Steinar Bang]

>>>>> Thomas Skogestad <tskogest@jusstud.uio.no>:

> But since 0.86 posting styles seems to behave a bit oddly. 

> If I try send a mail from a newsgroup, the mail inherits the
> settings for that group, even though I have specified separate
> settings for mail. This does not happen in 0.85.

How do you do that?  Ie. specify separate settings for mail?

The strange thing I've discovered, is that (in 0.97.1) the signature
is always inserted, even though I have
	(setq message-signature nil)
in ~/.gnus.el.

My hoped-for behaviour, was that this would make Gnus not insert the
signature by default, but use the specified signature file of the
posting styles for the group, if I did message-insert-signature.

I thought it might be something wrong with my posting styles, so I
haven't reported it as a bug.

Re: Pterodactyl Gnus v0.98 is released

[Thomas Skogestad]

* Steinar Bang

| How do you do that?  Ie. specify separate settings for mail?

I have 

         ("mail"
         ("mail-copies-to" nil)
         ("Reply-To" nil)
         (name "Thomas Skogestad")
         (address "thomas.skogestad@jusstud.uio.no")
         )

and such.

But then I use the code from 0.85 since 0.98 doesn't seem to like this.

-- 
thomas.skogestad@jusstud.uio.no
http://cgi.mercurycenter.com/premium/comics/10_13/dilbert.gif
http://buzz.bazooka.se/buzz/braz/ * http://www.istanbul.tc/mahir/
http://www.foxmovies.com/fightclub/flightcard_sm.jpg (minor spoiler)

Re: Pterodactyl Gnus v0.98 is released

[Thomas Skogestad]

* Thomas Skogestad

|          ("Reply-To" nil)

This doesn't work, though.

-- 
thomas.skogestad@jusstud.uio.no
http://cgi.mercurycenter.com/premium/comics/10_13/dilbert.gif
http://buzz.bazooka.se/buzz/braz/ * http://www.istanbul.tc/mahir/
http://www.foxmovies.com/fightclub/flightcard_sm.jpg (minor spoiler)

Re: Pterodactyl Gnus v0.98 is released

[Hrvoje Niksic]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Now lets get a real release.  Please.

I thought the release was supposed to include IMAP support?  Does it?

Re: Pterodactyl Gnus v0.98 is released

[Simon Josefsson]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> > Now lets get a real release.  Please.
> 
> I thought the release was supposed to include IMAP support?  Does it?

It's included.  Feedback appreciated.

There is one major problem [with nnimap] that would be good to have
solved before a real release though.

IMAP in Pterodactyl Gnus v0.98

[David Maslen]

Simon Josefsson <jas@pdc.kth.se> writes:

> Hrvoje Niksic <hniksic@iskon.hr> writes:
> 
> > > Now lets get a real release.  Please.
> > 
> > I thought the release was supposed to include IMAP support?  Does it?
> 
> It's included.  Feedback appreciated.
> 
> There is one major problem [with nnimap] that would be good to have
> solved before a real release though.

I'm considering using imap, but since my current nnfolder system is
working nicely...

Can I mix and match.

Have say my inbox and a couple of low volume folders on imap and my
existing mailing list, and other large groups as I have then now
stored locally in nnfolders?

Also what is the major problem that needs to be fixed. If I do go to
imap, i'd like to know what i'm letting myself in for. 

Re: IMAP in Pterodactyl Gnus v0.98

[Kai Großjohann]

David Maslen <david.maslen@iname.com> writes:

> Can I mix and match.  [nnimap and nnfolder]

Oh, yes.  You `just' need to arrange things so that the messages you
want on the IMAP server are sent to the IMAP server and that the
messages you want in nnfolder are sent to /var/spool/mail/jrl
automatically.

At our site, we're still experimenting with the IMAP setup, so all the
people who use IMAP have a .forward file which points to
`user+@imaphost'.  Note the `+' sign.  Mail to `user@imaphost' ends up
in /var/mail.  It should be obvious that users can also use procmail
to send some messages to the IMAP server and leave others in
/var/mail, just by having procmail forward the messages to the right
address. 

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: IMAP in Pterodactyl Gnus v0.98

[Simon Josefsson]

David Maslen <david.maslen@iname.com> writes:

> I'm considering using imap, but since my current nnfolder system is
> working nicely...
> 
> Can I mix and match.

Sure.

> Have say my inbox and a couple of low volume folders on imap and my
> existing mailing list, and other large groups as I have then now
> stored locally in nnfolders?

Yes. One caveat though: there is no splitting between backends. So you
can't split mail automatically into the correct nnimap/nnfolder group.

> Also what is the major problem that needs to be fixed. If I do go to
> imap, i'd like to know what i'm letting myself in for. 

Some immediate problems I'm aware of:

. the uidvalidity error message Denys mentioned. No harm caused, but
  it's annoying and will cause lots of confusion. I have a very ugly
  solution for it but I'm afraid to show it so I'm trying to come up
  with something better. :-)

. bogus new servers are created by Gnus as a result of changing the
  `gnus-secondary-select-methods' without resubscribing to old groups.

. some servers will require you to configure a `nnimap-list-pattern'
  to be usable with nnimap.

Re: IMAP in Pterodactyl Gnus v0.98

[Denys Duchier]

Simon Josefsson <jas@pdc.kth.se> writes:

> . bogus new servers are created by Gnus as a result of changing the
>   `gnus-secondary-select-methods' without resubscribing to old groups.

Aaaarghh!  Just as I was becoming semi-happy with IMAP, I decided to
rearrange my folders.  Now I have zillions of imap servers opened; one
for each of my folders.  I just had to login into every single one of
them.  My elation has quickly evaporated.

I am sure I didn't do things The Right Way(TM), of course not, it's
not documented!  It was suggested to me that I read nnimap's
documentation.  Right! great advice: where is it?  I can't seem to
find it in the release, nor in my last update from the CVS tree.

How do I put things right again?  I want these bogus servers to go
away, all of them, and never come back.  I also want to know how to
rearrange my folders without being catapulted into IMAP hell.

The weekend being almost over, this is becoming kind of really urgent
now.  Somebody save me, please?

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: IMAP in Pterodactyl Gnus v0.98

[Denys Duchier]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

> How do I put things right again?  I want these bogus servers to go
> away, all of them, and never come back.

I seem to have managed to fix things by manually removing my imap
folders from .newsrc.eld and then resubscribing through the imap
server.

My attack of panic is almost over :-)

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: IMAP in Pterodactyl Gnus v0.98

[Simon Josefsson]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

> > . bogus new servers are created by Gnus as a result of changing the
> >   `gnus-secondary-select-methods' without resubscribing to old groups.
> 
> Aaaarghh!  Just as I was becoming semi-happy with IMAP, I decided to
> rearrange my folders.  Now I have zillions of imap servers opened; one
> for each of my folders.  I just had to login into every single one of
> them.  My elation has quickly evaporated.

This is a side effect of removing a virtual server which has
subscribed groups on it -- Gnus then takes the "lets-do-what-we-can"
approach and create a new server for every group.

> I am sure I didn't do things The Right Way(TM), of course not, it's
> not documented!  It was suggested to me that I read nnimap's
> documentation.  Right! great advice: where is it?  I can't seem to
> find it in the release, nor in my last update from the CVS tree.

Gnus manual -> Select methods -> Other sources -> IMAP.

Altough I don't think this problem is very nnimap specific.

> How do I put things right again?  I want these bogus servers to go
> away, all of them, and never come back.

`C-k' your nnimap groups that has a different server than what's in
your `gnus-secondary-select-methods'. You can view/edit the server for
a group with `G e' on a group.

> I also want to know how to rearrange my folders without being
> catapulted into IMAP hell.

What do you mean by "rearrange my folders"?  Moving around groups with
kill/yank should work the same way with nnfolder groups as nnimap
groups.

Re: IMAP in Pterodactyl Gnus v0.98

[David Kågedal]

David Maslen <david.maslen@iname.com> writes:

> I'm considering using imap, but since my current nnfolder system is
> working nicely...
> 
> Can I mix and match.
> 
> Have say my inbox and a couple of low volume folders on imap and my
> existing mailing list, and other large groups as I have then now
> stored locally in nnfolders?

I've done it the other way around.  I moved linux-kernel (very high
volume) to imap and kept low-volume stuff on nnfolder.  Using nnfolder
for high-volume lists is slow.

-- 
David Kågedal

Re: Pterodactyl Gnus v0.98 is released

[Dave Love]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

 Per> It probably won't be in time for Emacs 20.5, although that would
 Per> have been nice.

It wouldn't be appropriate for 20.5 anyway.

0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

>>"P" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

    P> Now lets get a real release.  Please.  It is getting really
    P> difficult to justify advising newbies against pGnus, especially
    P> if they want to use it for mail.

Well, with all this enthusiasm around, and encouraged by seeing that
working with the Server buffer seemed to be free of significant bugs,
I got a bit bolder and started to use topics in the Group buffer.  Big
mistake.  The first sign something was wrong was when my one zombie
group kept popping up in weird places, duplicating itself.  Generally
when this ghost-of-a-zombie appeared, I could kill it but not yank it
again.

On quitting Gnus/Emacs and restarting, I found that my entire Gnus
state in .newsrc had been blown away.  I lost everything but the list
of subscribed groups (no levels, no history of read articles, etc.).

Seems to me that you don't want to call a program that looses
important data so easily even 'beta', much less `stable'.

I don't point this out to complain, but if you ask me whether pGnus
0.98 is close to graduating from `alpha' status, my answer is
emphatically 'no'.

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Per Abrahamsen]

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

> I don't point this out to complain, but if you ask me whether pGnus
> 0.98 is close to graduating from `alpha' status, my answer is
> emphatically 'no'.

But you seem to be the only one suffering from all these problems.
The best bet is that it is something specific to your site, maybe some
weird customizations, or some old files somewhere in the path.

Thus, nothing Lars can do with Gnus will make your installation work
better.  

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

>>"P" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

    P> But you seem to be the only one suffering from all these
    P> problems.  The best bet is that it is something specific to
    P> your site, maybe some weird customizations, or some old files
    P> somewhere in the path.

Am I?  No one's told me that they can't reproduce anything I've
described how to reproduce on my system.  

Can you see groups in your Group buffer with level L where
gnus-activate-level < L < gnus-level-zombie?  (i.e., level 7 with
standard settings).  Set one group to level 7, and restart Emacs.  I
think you'll be able to see it before you restart, but not after, even
with a `9L' command.

Gnus doesn't load its code from a lot of places.  All the pgnus files
live in one directory, so since I get `gnus-version' of "Pterodactl
Gnus v0.98" I've got all the core files in the right place.  I don't
have ~/.gnus, and I keep (having to) start over with rm .newsrc*.  As
for customizations, I just spent an hour going over everything below
'M-x customize-group gnus' for a sanity check.  I don't have many (if
any) freeform customizations, i.e., changes that aren't just a toggle
or value-menu choice.  If it's faulty customization alone, then the
`bug' should still be reproducible using the environment that gets
included by `gnus-bug'.

    P> Thus, nothing Lars can do with Gnus will make your installation
    P> work better.

That's only a guess for now.  It's not established that anything my
Gnus is doing reproducibly is different from anyone else's Gnus.  If I
establish that, then it will be demonstrated that my environment
compromises Gnus somehow, but until then, I'm assuming that these bad
'random' things just haven't hit anyone else who bothers to report
them yet.  Gnus is a very complex program, and it wouldn't surprise me
that only one person who bothers to report bugs on pGnus has a usage
pattern that triggers a given bug.

So ignore the mysterious crashes, since I can't reproduce them.  I've
still submitted four obvious, reproducible bugs in the last 24 hours.
I mean ones in which the mistake is an obvious one, like a quoting
problem, or failure to handle a foreign group in a certain situation.
Ones I could provide fixes for if I had days of time to spare.  I've
got a couple more that will take some more time to report properly
upon -- I keep having to start from scratch.

It doesn't matter to me personally whether pGnus stays `alpha' or gets
touted as %100 bug-free.  I will be submitting the same bug reports.

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Kai Großjohann]

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

> Can you see groups in your Group buffer with level L where
> gnus-activate-level < L < gnus-level-zombie?  (i.e., level 7 with
> standard settings).  Set one group to level 7, and restart Emacs.  I
> think you'll be able to see it before you restart, but not after, even
> with a `9L' command.

For me, gnus-activate-level is 4 and gnus-level-zombie is 8.  I tried
your recipe: I chose a group with 0 unread messages, and typed S l 5
RET.  I then quit Emacs and restarted it.  The group appeared in the
Group buffer with a * in front of it.

I'll try level 7 next and see if that makes a difference.  You will
hear from me if it does.

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Kai Großjohann]

Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> I'll try level 7 next and see if that makes a difference.  You will
> hear from me if it does.

Now the group didn't appear, but typing `L' made it appear (with `U'
and `*' in front of it).

It is really strange that you can see such behavior but nobody else
seems to be able to :-/

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

>>"K" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    K> Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    K> For me, gnus-activate-level is 4 and gnus-level-zombie is 8.  I
    K> tried your recipe: I chose a group with 0 unread messages, and
    K> typed S l 5 RET.  I then quit Emacs and restarted it.  The
    K> group appeared in the Group buffer with a * in front of it.

    [ now, setting the group to 7 ]

    K> Now the group didn't appear, but typing `L' made it appear
    K> (with `U' and `*' in front of it).

That's correct behavior if your gnus-level-subscribed is 5 or 6.  Is
it?  You are using 0.98 and emacs 20.4?  (as you do when sending to
the rcp.el list, but the mail-news gateway is chopping your
User-Agent:)

If so, I'll accept the possibility that it's my environment, and
devote hours and hours to hand tracing every line of LISP.

Would you send me a mail privately that's generated by C-c C-b
(`gnus-bug') with the To: address changed to me?  This will allow me
to set my variable state to yours and eliminate that possible cause.

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Jody M. Klymak]

Hi Matt,

I get the same result as Kai, but I'm using Emacs 20.4, Pgnus 0.97.
Is this problem new with 0.98?  I haven't upgraded yet!

gnus-level-subscribed is 5

Cheers,  Jody

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

    >>> "K" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
    >>> writes:
    K> Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    K> For me, gnus-activate-level is 4 and gnus-level-zombie is 8.  I
    K> tried your recipe: I chose a group with 0 unread messages, and
    K> typed S l 5 RET.  I then quit Emacs and restarted it.  The
    K> group appeared in the Group buffer with a * in front of it.

    MS>     [ now, setting the group to 7 ]

    K> Now the group didn't appear, but typing `L' made it appear
    K> (with `U' and `*' in front of it).

    MS> That's correct behavior if your gnus-level-subscribed is 5 or
    MS> 6.  Is it?  You are using 0.98 and emacs 20.4?  (as you do
    MS> when sending to the rcp.el list, but the mail-news gateway is
    MS> chopping your User-Agent:)

    MS> If so, I'll accept the possibility that it's my environment,
    MS> and devote hours and hours to hand tracing every line of LISP.

    MS> Would you send me a mail privately that's generated by C-c C-b
    MS> (`gnus-bug') with the To: address changed to me?  This will
    MS> allow me to set my variable state to yours and eliminate that
    MS> possible cause.

-- 
Jody Klymak                         APL/School of Oceanography,
Doctoral Candidate                  University of Washington
mailto:jklymak@apl.washington.edu   (206)-685-9080
http://www.ocean.washington.edu/people/grads/jklymak/

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

>>"JMK" == Jody M Klymak <jklymak@apl.washington.edu> writes:

    JMK> Hi Matt,

    JMK> I get the same result as Kai, but I'm using Emacs 20.4, Pgnus
    JMK> 0.97.  Is this problem new with 0.98?

If it's a problem with Gnus, it's been there since at least 0.96.

If you don't have this problem with 0.97, I strongly doubt you will in
0.98.

Either it's a problem with my environment (and possibly others'), a
misconfiguration of Gnus (unlikely), or a problem with Gnus that is
triggered by certain unusual but legitimate configurations.  

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Kai Großjohann]

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

> That's correct behavior if your gnus-level-subscribed is 5 or 6.  Is
> it?  You are using 0.98 and emacs 20.4?  (as you do when sending to
> the rcp.el list, but the mail-news gateway is chopping your
> User-Agent:)

I now use the 20.5 pretest, but I don't think that makes a
difference.  Yes, gnus-level-subscribed is 5.

> If so, I'll accept the possibility that it's my environment, and
> devote hours and hours to hand tracing every line of LISP.
> 
> Would you send me a mail privately that's generated by C-c C-b
> (`gnus-bug') with the To: address changed to me?  This will allow me
> to set my variable state to yours and eliminate that possible cause.

Sure, you already have the message.

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

>>"K" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    K> Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
    >> I'll try level 7 next and see if that makes a difference.  You
    >> will hear from me if it does.

    K> Now the group didn't appear, but typing `L' made it appear
    K> (with `U' and `*' in front of it).

Would you mind trying the same with a group set to level 8
(gnus-level-zombie)?  

Lee Willis wrote me privately saying that he can't see groups with
level 7 OR 8 when he says `9 L', but he argues that this is the way
Gnus is *supposed* to behave.  I'm going to ignore how I think Gnus
ought to behave for the time being, and try to figure out more simply
just what determines its behavior.

Now, I've asked you both for further details, but it seems that my
system, your system, and Lee's system, are all behaving differently.

Z = gnus-level-zombie, Z > (1+ gnus-activate-level), Z+1 = gnus-level-killed

(with Gnus default values, Z=8)

          Z-1       Z
     -----------------------
  me:    no        yes
 Lee:    no         no
 Kai:   yes         ?


If confirmed, this leads me to believe that another Gnus variable is
relevant (and probably relevant when it shouldn't be relevant).
I have gnus-save-killed-list set to nil.  What about you?  What other
candidates haven't we mentioned?

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Kai Großjohann]

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

> Would you mind trying the same with a group set to level 8
> (gnus-level-zombie)?  

Very interesting.  The group is marked with `K' (not `Z'!), and it is
not listed.  That's strange.  `9 L' shows a number of killed messages,
as well as a number of zombie messages, but it doesn't show this one!

_Now_ I see what you are talking about.

OK.  What have I got?

(list gnus-activate-level gnus-level-subscribed
gnus-level-unsubscribed gnus-level-zombie gnus-level-killed)
=> (4 5 7 8 9)

And doing `S l 8 RET' on a group makes it display with `K', and it
doesn't show up after `9 L'.  It doesn't show up in `A k' or `A z',
either.

So, who else can verify the bug according to the recipe?

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Matt Swift]

>>"K" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    K> And doing `S l 8 RET' on a group makes it display with `K', and
    K> it doesn't show up after `9 L'.  It doesn't show up in `A k' or
    K> `A z', either.

I think there are some additional subtle features of working with
zombie groups.  I noted them and set them aside until I resolved the
major levels & listings problem (which I have, see post and copy to
you).

Perhaps think your steps above through again, knowing what you do now,
that what's key is whether the group is activated.

What I've noticed:

1) you can't `catch up' a zombie group

2) if you kill a zombie group with C-k and try to yank it (suppose you
   want to move it around), you can't yank it.

I have not decided whether these are bugs or features.

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Jody M. Klymak]

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

    MS> If confirmed, this leads me to believe that another Gnus
    MS> variable is relevant (and probably relevant when it shouldn't
    MS> be relevant).  I have gnus-save-killed-list set to nil.  What
    MS> about you?  What other candidates haven't we mentioned?

Hi Matt, 

gnus-saved-killed-list is set to t for me, the default I presume.  Is
this the problem perhaps?  

This is all very interesting.  To be honest I haven't understood
(groked, in Kai-speak) the subtle differences between zombie, killed,
and unsubscribed.  It all seems a little needlessly complicated to me.
Whats wrong with subscribing or unsubscribing?  Does anyone actively
use all this stuff?  Is it of great use?  I understand the need for
levels, but to be honest I only use 1-3 for subscribed groups, 1 for
personal mail, 2 for important lists/groups, and 3 for stuff I check
daily or so.  

Cheers,  Jody

-- 
Jody Klymak                         APL/School of Oceanography,
Doctoral Candidate                  University of Washington
mailto:jklymak@apl.washington.edu   (206)-685-9080
http://www.ocean.washington.edu/people/grads/jklymak/

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Kai Großjohann]

The difference between unsubscribed and the other two levels is that
Gnus doesn't show those groups by default, but information is still
gathered for them (eg lowest/highest article number).  Entering these
groups is fast, as for subscribed groups.  (Entering killed or zombie
groups is slower.)

In a way, unsubscribed groups are just like subscribed ones, only
hidden.

Zombie groups come into play when you don't want to subscribe new
newsgroups, but you still want a way to distinguish groups that newly
arrived on the server.  You tell Gnus to subscribe new groups as
zombies, then you type `A z' every once in a while, and subscribe the
(new) groups that you like and kill the rest.

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

error and fix in `gnus-group-prepare-flat' (was: 0.98 + topics = catastrophe)

[Matt Swift]

I've found the problem (or, one of them).  I am the first to admit I
often make stupid mistakes.  This time, however, I was not making any
mistakes.  What I've found in the sources coincides exactly with the
behvaior I've observed from my Gnus.

This leaves an interesting question that I can not begin to answer,
why some people on emacs.ding claimed they couldn't duplicate it.  Do
they have a non-default setting for `gnus-group-prepare-function'?  An
altered `gnus-group-prepare-flat' or `gnus-get-unread-articles'?

This is from `gnus-group-prepare-flat' (in gnus-group.el), which is
the default value of `gnus-group-prepare-function' function that lists
the groups in the Group buffer,

         ;; for each group:
	 (let 
          ;; ...  
	    unread (car (gnus-gethash group gnus-newsrc-hashtb)))
        ;; ...
        ;;; the following applies to living groups, i.e., l < gnus-level-zombie
	(and unread			; This group might be bogus
	     ;;  ...
	     (or all			; We list all groups?
		 (if (eq unread t)	; Unactivated?
		     gnus-group-list-inactive-groups ; We list unactivated
		   (> unread 0))	; We list groups with unread articles
		 ;; ...

            ;; LIST THE GROUP

(The parameter `all' is passed to the function, and is nil on the
initial invocation of this function at startup.)

Therefore, a group will not be listed if the value of `unread' is nil.

The value that `unread' is assigned is originally assigned in
`gnus-get-unread-articles', called as a result of calling `gnus':

  `unread' is n>0 for an   active group with    unread messages
  `unread' is   0 for an   active group with no unread messages
  `unread' is nil for an inactive group (with or without unread messages)
  `unread' it   t for a  bogus    group (and for other unreachable groups)     

(Actually, the value starts as nil, and `gnus-get-unread-articles'
does not change it for inactive groups.)

A "bogus" group is one that exists in .newsrc but not on the server.

The comment "This group might be bogus" could mean one of two things.
It could mean that since `gnus-get-unread-articles' has skipped
contacting the server regarding this group, Gnus has not confirmed
that the group exists on the server, and that this is the reason why
such groups are *not permitted*.  Alternatively, if `unread' is not
expected to have a value of nil, the comment could refer to those
groups which the line *permits*.  These, too, are at risk of being
bogus, since the server could not be polled regarding this group for
some reason.

My interpretation is that the author of the comment meant the latter,
that is, did not expect `unread' to ever be nil.  The "Unactivated?"
comment later lends strength to this interpretation.  `unread' for
unactivated groups has a value of EITHER nil OR t, not just t.

The behavior of this function is not documented, and judging from the
comments in the `gnus-group-prepare-flat' function, it is not
intentional either.  The comment "This group might be bogus" conflicts
with the later logic that definitely intends to list unactivated
groups (`gnus-group-list-inactive-groups' permitting, and by default
it does).  Additionally, `gnus-group-prepare-flat' is called when gnus
starts with the `all' argument t, obviating any consultation of
`gnus-group-list-inactive-groups'.

Other people (e.g., Kai, Per) on emacs.ding who for whatever
mysterious reason *do* see live-but-inactive groups in their Group
buffers consider it the proper behavior.  I agree it is proper
behavior.  To get Gnus to do what's proper, I need to alter the quoted
part of the function to read:

	(and (or (not regexp)
		 (string-match regexp group))
	     (<= (setq clevel (gnus-info-level info)) level)
	     (>= clevel lowest)
	     (or all			; We list all groups?
		 (if (integerp unread)
		     (> unread 0)	; We list groups with unread articles
		   gnus-group-list-inactive-groups) ; Maybe list unactivated
             ;; ETC

Re: error and fix in `gnus-group-prepare-flat' (was: 0.98 + topics = catastrophe)

[Matt Swift]

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

    M> permitting, and by default it does).  Additionally,
    M> `gnus-group-prepare-flat' is called when gnus starts with the
    M> `all' argument t, obviating any consultation of
    M> `gnus-group-list-inactive-groups'.

strike that sentence: it's wrong, as I mentioned elsewhere in the post.

Re: 0.98 + topics = catastrophe (Was: Pterodactyl Gnus v0.98 is released)

[Lee Willis]

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

> Lee Willis wrote me privately saying that he can't see groups with
> level 7 OR 8 when he says `9 L', but he argues that this is the way
> Gnus is *supposed* to behave.

Sorry I didn't intend saying that I knew how gnus was supposed to work,
I just meant that what happened with me seemed to make sense as to *how
I thought* it was supposed to behave ...

> Now, I've asked you both for further details, but it seems that my
> system, your system, and Lee's system, are all behaving differently.

Just to confuse the issue, mine is now behaving differently again :(

> Z = gnus-level-zombie, Z > (1+ gnus-activate-level), Z+1 = gnus-level-killed
> 
> (with Gnus default values, Z=8)
> 
>           Z-1       Z
>      -----------------------
>   me:    no        yes
>  Lee:    no         no
>  Kai:   yes         ?

If I set two groups' levels, ie. On Gnus I do Sl7 and on Gnus-Patches I
do Sl8  then I see the following :

Gnus gets a U next to it and remains in the display. If I restart it
still appears as an unsubscribed group.

Gnus-Patches disappears never to be seen again until I j to the
group. An A z doesn't find it, neither does an A k. When I j to the
group it appears with a K in front of it.

My gnus now appears to be behaving like Kai's for some reason where it
didn't yesterday ...  I've upgraded to 0.98 but I don't think that
should have changed anything.

Sorry for the confusion guys ...

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"