* gnus-group-suspend forgets "readedness" of newly read articles
@ 2001-02-07 16:57 Dmitry Yaitskov
2001-02-07 17:03 ` Karl Kleinpaste
0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Yaitskov @ 2001-02-07 16:57 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 16:57 gnus-group-suspend forgets "readedness" of newly read articles Dmitry Yaitskov
@ 2001-02-07 17:03 ` Karl Kleinpaste
2001-02-07 17:29 ` Toby Speight
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Karl Kleinpaste @ 2001-02-07 17:03 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 17:03 ` Karl Kleinpaste
@ 2001-02-07 17:29 ` Toby Speight
2001-02-07 18:02 ` Dmitry Yaitskov
2001-02-07 18:03 ` Dmitry Yaitskov
2001-02-08 15:43 ` Kai Großjohann
2 siblings, 1 reply; 13+ messages in thread
From: Toby Speight @ 2001-02-07 17:29 UTC (permalink / raw)
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*.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 17:29 ` Toby Speight
@ 2001-02-07 18:02 ` Dmitry Yaitskov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Yaitskov @ 2001-02-07 18:02 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 17:03 ` Karl Kleinpaste
2001-02-07 17:29 ` Toby Speight
@ 2001-02-07 18:03 ` Dmitry Yaitskov
2001-02-07 18:50 ` Karl Kleinpaste
2001-02-08 15:43 ` Kai Großjohann
2 siblings, 1 reply; 13+ messages in thread
From: Dmitry Yaitskov @ 2001-02-07 18:03 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 18:03 ` Dmitry Yaitskov
@ 2001-02-07 18:50 ` Karl Kleinpaste
2001-02-07 18:59 ` Paul Jarc
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Karl Kleinpaste @ 2001-02-07 18:50 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 18:50 ` Karl Kleinpaste
@ 2001-02-07 18:59 ` Paul Jarc
2001-02-07 19:30 ` Dmitry Yaitskov
2001-02-08 0:08 ` Andreas Fuchs
2 siblings, 0 replies; 13+ messages in thread
From: Paul Jarc @ 2001-02-07 18:59 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 18:50 ` Karl Kleinpaste
2001-02-07 18:59 ` Paul Jarc
@ 2001-02-07 19:30 ` Dmitry Yaitskov
2001-02-08 1:17 ` Dan Christensen
2001-02-08 0:08 ` Andreas Fuchs
2 siblings, 1 reply; 13+ messages in thread
From: Dmitry Yaitskov @ 2001-02-07 19:30 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 18:50 ` Karl Kleinpaste
2001-02-07 18:59 ` Paul Jarc
2001-02-07 19:30 ` Dmitry Yaitskov
@ 2001-02-08 0:08 ` Andreas Fuchs
2 siblings, 0 replies; 13+ messages in thread
From: Andreas Fuchs @ 2001-02-08 0:08 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 19:30 ` Dmitry Yaitskov
@ 2001-02-08 1:17 ` Dan Christensen
2001-02-08 2:19 ` Karl Kleinpaste
2001-02-11 15:03 ` ShengHuo ZHU
0 siblings, 2 replies; 13+ messages in thread
From: Dan Christensen @ 2001-02-08 1:17 UTC (permalink / raw)
Cc: Ding
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-08 1:17 ` Dan Christensen
@ 2001-02-08 2:19 ` Karl Kleinpaste
2001-02-11 15:03 ` ShengHuo ZHU
1 sibling, 0 replies; 13+ messages in thread
From: Karl Kleinpaste @ 2001-02-08 2:19 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-07 17:03 ` Karl Kleinpaste
2001-02-07 17:29 ` Toby Speight
2001-02-07 18:03 ` Dmitry Yaitskov
@ 2001-02-08 15:43 ` Kai Großjohann
2 siblings, 0 replies; 13+ messages in thread
From: Kai Großjohann @ 2001-02-08 15:43 UTC (permalink / raw)
Cc: ding
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gnus-group-suspend forgets "readedness" of newly read articles
2001-02-08 1:17 ` Dan Christensen
2001-02-08 2:19 ` Karl Kleinpaste
@ 2001-02-11 15:03 ` ShengHuo ZHU
1 sibling, 0 replies; 13+ messages in thread
From: ShengHuo ZHU @ 2001-02-11 15:03 UTC (permalink / raw)
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)))))
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2001-02-11 15:03 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-07 16:57 gnus-group-suspend forgets "readedness" of newly read articles Dmitry Yaitskov
2001-02-07 17:03 ` Karl Kleinpaste
2001-02-07 17:29 ` Toby Speight
2001-02-07 18:02 ` Dmitry Yaitskov
2001-02-07 18:03 ` Dmitry Yaitskov
2001-02-07 18:50 ` Karl Kleinpaste
2001-02-07 18:59 ` Paul Jarc
2001-02-07 19:30 ` Dmitry Yaitskov
2001-02-08 1:17 ` Dan Christensen
2001-02-08 2:19 ` Karl Kleinpaste
2001-02-11 15:03 ` ShengHuo ZHU
2001-02-08 0:08 ` Andreas Fuchs
2001-02-08 15:43 ` Kai Großjohann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).