From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/34613 Path: main.gmane.org!not-for-mail From: Dmitry Yaitskov Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus-group-suspend forgets "readedness" of newly read articles Date: 07 Feb 2001 14:30:29 -0500 Organization: Just me at home Sender: owner-ding@hpc.uh.edu Message-ID: <873ddq1eay.fsf@home.com> References: <87snlq1lds.fsf@home.com> <87hf261icl.fsf@home.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035170508 31307 80.91.224.250 (21 Oct 2002 03:21:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:21:48 +0000 (UTC) Return-Path: Original-Received: from karazm.math.uh.edu (karazm.math.uh.edu [129.7.128.1]) by mailhost.sclp.com (Postfix) with ESMTP id 0CF55D049D for ; Wed, 7 Feb 2001 14:31:41 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id NAC08617; Wed, 7 Feb 2001 13:31:16 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 07 Feb 2001 13:30:33 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id NAA13648 for ; Wed, 7 Feb 2001 13:30:23 -0600 (CST) Original-Received: from lucy.on.wave.home.com (unknown [24.66.110.146]) by mailhost.sclp.com (Postfix) with ESMTP id 3908BD049D for ; Wed, 7 Feb 2001 14:30:47 -0500 (EST) Original-Received: from Spooler by lucy.on.wave.home.com (Mercury/32 v3.21c) ID MO0004C0; 7 Feb 01 14:30:47 -0500 Original-Received: from spooler by lucy.on.wave.home.com (Mercury/32 v3.21c); 7 Feb 01 14:30:32 -0500 Original-Received: from lucy.on.wave.home.com (127.0.0.1) by lucy.on.wave.home.com (Mercury/32 v3.21c) with ESMTP ID MG0004BF; 7 Feb 01 14:30:29 -0500 Original-To: Ding In-Reply-To: (Karl Kleinpaste's message of "07 Feb 2001 13:50:46 -0500") User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) Precedence: list X-Majordomo: 1.94.jlt7 Original-Lines: 51 Xref: main.gmane.org gmane.emacs.gnus.general:34613 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:34613 Karl Kleinpaste writes: > Dmitry Yaitskov 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.