strange bug in the *Group* buffer...

strange bug in the *Group* buffer...

[Josh Huber]

Something I've been seeing lately in the group buffer is this:

c y (to mark all messages in a group as read) causes the current line
to be *unchanged* while a duplicate showing all the messages marked as
read is appended to the bottom of the buffer.

A picture shows this the best:

http://www.paradoxical.net/~huber/funnybug.png

See where the point is?  This is the phantom group, while the original
(unchanged) group is still under the "Linux" topic.

Any ideas?  I think this started happening recently...

-- 
Josh Huber

Re: strange bug in the *Group* buffer...

[Simon Josefsson]

Josh Huber <huber@alum.wpi.edu> writes:

> Something I've been seeing lately in the group buffer is this:
>
> c y (to mark all messages in a group as read) causes the current line
> to be *unchanged* while a duplicate showing all the messages marked as
> read is appended to the bottom of the buffer.
>
> A picture shows this the best:
>
> http://www.paradoxical.net/~huber/funnybug.png
>
> See where the point is?  This is the phantom group, while the original
> (unchanged) group is still under the "Linux" topic.
>
> Any ideas?  I think this started happening recently...

What does `G E' on the groups reveal?  Do the server match the one you
define in `g-s-m' or `g-s-s-m'?

Re: strange bug in the *Group* buffer...

[Josh Huber]

Simon Josefsson <jas@extundo.com> writes:

> What does `G E' on the groups reveal?  Do the server match the one you
> define in `g-s-m' or `g-s-s-m'?

These are all nnml groups:

(setq gnus-select-method '(nnml ""))

This is what G E shows:

("mail.lists.linuxppc.embedded" 2
 ((1 . 5403))
 ((seen
   (4217 . 5198))))

Running G E on the "phantom" group after c y shows the same, except
for the article range has changed to include all the articles.  In
this case it changed from (1 . 5403) to (1 . 5404), which is correct
(I think) since there was only 1 unread message.

hmm

-- 
Josh Huber