gnus-group-suspend forgets "readedness" of newly read articles

gnus-group-suspend forgets "readedness" of newly read articles

[Dmitry Yaitskov]

More or less subj. In a group (I tested an nnml one), I read some new
messages. Then without quitting the summary buffer, go to the group
buffer and press z. The opened group gets closed and gnus goes to the
bottom. If I then open the same group, the articles that I have read
during the last session are not marked as such.

XEmacs 21.2  (beta43) "Terspichore" [Lucid] (i686-pc-cygwin) of Tue Jan 30 2001 on LUCY
Oort Gnus v0.01

-- 
Cheers,
-Dima.

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Karl Kleinpaste]

This is not specific to gnus-group-suspend.  Any time that you are in
*Group* and select a group, you get a *Summary* based on what is known
at the time in the *Group* buffer.  The reason is that updates to
*Group* are made on exit from *Summary*.  If you do not exit *Summary*
in a way which allows Gnus to carry out normal updates, Gnus will
simply start over again when you re-select the same group.

This is not a bug.  Perhaps it needs explanation somewhere, though.

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Toby Speight]

0> In article <vxkpugupgrv.fsf@cinnamon.vanillaknot.com>,
0> Karl Kleinpaste <URL:mailto:karl@charcoal.com> ("Karl") wrote:

Karl> ... updates to *Group* are made on exit from *Summary*.  If you
Karl> do not exit *Summary* in a way which allows Gnus to carry out
Karl> normal updates, Gnus will simply start over again when you
Karl> re-select the same group.
Karl>
Karl> This is not a bug.  Perhaps it needs explanation somewhere,
Karl> though.

Perhaps the explanation should mention "Z s" (gnus-summary-save-newsrc
&optional FORCE), which updates the *Group* buffer without exiting
*Summary*.

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Dmitry Yaitskov]

Toby Speight <streapadair@gmx.net> writes:

> 0> In article <vxkpugupgrv.fsf@cinnamon.vanillaknot.com>,
> 0> Karl Kleinpaste <URL:mailto:karl@charcoal.com> ("Karl") wrote:
> 
> Karl> ... updates to *Group* are made on exit from *Summary*.  If you
> Karl> do not exit *Summary* in a way which allows Gnus to carry out
> Karl> normal updates, Gnus will simply start over again when you
> Karl> re-select the same group.
> Karl>
> Karl> This is not a bug.  Perhaps it needs explanation somewhere,
> Karl> though.
> 
> Perhaps the explanation should mention "Z s" (gnus-summary-save-newsrc
> &optional FORCE), which updates the *Group* buffer without exiting
> *Summary*.

Thanks.

-- 
Cheers,
-Dima.

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Dmitry Yaitskov]

Karl Kleinpaste <karl@charcoal.com> writes:

> This is not specific to gnus-group-suspend.  Any time that you are in
> *Group* and select a group, you get a *Summary* based on what is known
> at the time in the *Group* buffer.  The reason is that updates to
> *Group* are made on exit from *Summary*.  If you do not exit *Summary*
> in a way which allows Gnus to carry out normal updates, Gnus will
> simply start over again when you re-select the same group.
> 
> This is not a bug.  Perhaps it needs explanation somewhere, though.

Thanks for the explanation, but FWIW I disagree that it is not a bug.
"Forgetting" an action that the user has taken is akin to forgetting
e.g. that a file has been changed in a text editor. Imagine a feature
that would "suspend" (whatever that means) an edit session but will
lose all changes you have made to the files w/out so much as asking
you. There may be a technical reason for what's happening but it is
still bad UI. Same as Gnus asks about changes made to a new unsent
message it should ask about updating summaries (or update them
silently). IMHO.

-- 
Cheers,
-Dima.

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Karl Kleinpaste]

Dmitry Yaitskov <dimas@home.com> writes:
> There may be a technical reason for what's happening but it is
> still bad UI.

I guess I'd have to ask what you were doing back in *Group*, and
outside an "unresolved" (unaccounted-for?) *Summary*, in the first
place so that the question can even arise.

That is, by the manner in which you were using Gnus, you had subverted
a piece of its intended UI mechanism.  (Enter group from *Group*; read
articles from *Summary*; exit *Summary* properly to induce updates in
*Group*.)  Having successively subverted that, you then complain that
it didn't watch closely enough as you did it.

I see the point you're trying to make, but I see it as akin to someone
complaining that their car's transmission was left on the highway in
pieces as they shifted into reverse while racing.  Sure, you can do
that -- but what were you doing it for, and why is the damage done
considered to be the fault of the car?

About the most "fix" I could see for this would be for
gnus-group-suspend to refuse to do its thing if it saw any
unaccounted-for *Summary* buffers lying around, which would analogize
to a transmission interlock to prevent shifting into reverse.

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Paul Jarc]

Karl Kleinpaste <karl@charcoal.com> writes:
> About the most "fix" I could see for this would be for
> gnus-group-suspend to refuse to do its thing if it saw any
> unaccounted-for *Summary* buffers lying around, which would analogize
> to a transmission interlock to prevent shifting into reverse.

Is there any reason the *Group* buffer couldn't be updated
continuously?  Instead of batching things together in *Summary* and
then handing a big set of changes to *Group* (and backends), why not
let *Group* and backends be immediately notified of any changes?


paul

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Dmitry Yaitskov]

Karl Kleinpaste <karl@charcoal.com> writes:

> Dmitry Yaitskov <dimas@home.com> writes:
> > There may be a technical reason for what's happening but it is
> > still bad UI.
> 
> I guess I'd have to ask what you were doing back in *Group*, and
> outside an "unresolved" (unaccounted-for?) *Summary*, in the first
> place so that the question can even arise.
> 
> That is, by the manner in which you were using Gnus, you had subverted
> a piece of its intended UI mechanism.  (Enter group from *Group*; read
> articles from *Summary*; exit *Summary* properly to induce updates in
> *Group*.)  Having successively subverted that, you then complain that
> it didn't watch closely enough as you did it.
> 
> I see the point you're trying to make, but I see it as akin to someone
> complaining that their car's transmission was left on the highway in
> pieces as they shifted into reverse while racing.  Sure, you can do
> that -- but what were you doing it for, and why is the damage done
> considered to be the fault of the car?

Sorry, but that's BS. I am not sure what you mean by Gnus' "intended
UI mechanism". Multi-window, multi-process GUI systems were invented
to allow the user to switch from one activity/window/etc. to another
without concern for the "intended UI mechanism" (read predefined
sequence of actions). It is perfectly ok to open several summaries,
and keep them open at the same time. I do not have to exit one summary
to open another. I don't remember reading anywhere in Gnus docs that
using list-buffers was illegal while in a summary buffer. And I don't
*have* to remember that I have groups open when I suspend Gnus any
more that I have to remember whether I have made any changes to a
document in an editor when I close it - the program should keep track
of it.

As far as your comparison to shifting into reverse while racing
goes... although it is IMO completely bogus, it still would obviously
be a good feature if it were impossible to shift into reverse at any
forward speed that would result in damage. The fact that it may be
technically difficult is irrelevant.

> About the most "fix" I could see for this would be for
> gnus-group-suspend to refuse to do its thing if it saw any
> unaccounted-for *Summary* buffers lying around, which would analogize
> to a transmission interlock to prevent shifting into reverse.
> 
> 

-- 
Cheers,
-Dima.

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Andreas Fuchs]

On 2001-02-07, Karl Kleinpaste <karl@charcoal.com> wrote:
> That is, by the manner in which you were using Gnus, you had subverted
> a piece of its intended UI mechanism.  (Enter group from *Group*; read
> articles from *Summary*; exit *Summary* properly to induce updates in
> *Group*.)

See the info docs, topic Windows Configuration. Hint: search for
"Example".

-- 
Andreas Fuchs, <asf@acm.org>, <d96001@htlwrn.ac.at>, antifuchs

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Dan Christensen]

Dmitry Yaitskov <dimas@home.com> writes:

> Karl Kleinpaste <karl@charcoal.com> writes:
> 
> > Dmitry Yaitskov <dimas@home.com> writes:
> > > There may be a technical reason for what's happening but it is
> > > still bad UI.
> > 
> > I guess I'd have to ask what you were doing back in *Group*, and
> > outside an "unresolved" (unaccounted-for?) *Summary*, in the first
> > place so that the question can even arise.
> 
> Sorry, but that's BS. I am not sure what you mean by Gnus' "intended
> UI mechanism". Multi-window, multi-process GUI systems were invented
> to allow the user to switch from one activity/window/etc. to another
> without concern for the "intended UI mechanism"

I agree with Dmitry here.  The behavior of gnus-group-exit (bound to
`q' in the *Group* buffer) suggests that Gnus knows how to handle
active summary buffers.  Why doesn't gnus-group-suspend call
gnus-offer-save-summaries like gnus-group-exit does?

Dan

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Karl Kleinpaste]

Dan Christensen <jdc@uwo.ca> writes:
> I agree with Dmitry here.

Having thought it through some more, I find now I do, too.

> Why doesn't gnus-group-suspend call gnus-offer-save-summaries like
> gnus-group-exit does?

It would work for me.

Re: gnus-group-suspend forgets "readedness" of newly read articles

[Kai Großjohann]

On 07 Feb 2001, Karl Kleinpaste wrote:

> This is not specific to gnus-group-suspend.  Any time that you are
> in *Group* and select a group, you get a *Summary* based on what is
> known at the time in the *Group* buffer.

When I enter a group, then `C-x b *Group* RET' from that summary
buffer, then enter the same group again from the *Group* buffer, I get
the already-open summary buffer.  So it's not based on what's known in
the group buffer, it's the same summary buffer that's already open.

This has been like this for a long time.

What gives?

kai
-- 
Be indiscrete.  Do it continuously.

Re: gnus-group-suspend forgets "readedness" of newly read articles

[ShengHuo ZHU]

Dan Christensen <jdc@uwo.ca> writes:


[...]

> I agree with Dmitry here.  The behavior of gnus-group-exit (bound to
> `q' in the *Group* buffer) suggests that Gnus knows how to handle
> active summary buffers.  Why doesn't gnus-group-suspend call
> gnus-offer-save-summaries like gnus-group-exit does?

Added.

ShengHuo

-- 
(setq gnus-posting-styles 
      '((".*" (signature (format "(setq gnus-posting-styles 
      '%S)" gnus-posting-styles)))))