From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/52124 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: Overbearing undownloaded face Date: Thu, 01 May 2003 23:01:26 -0500 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <87wuha9kpf.fsf@enberg.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1051848063 18473 80.91.224.249 (2 May 2003 04:01:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 2 May 2003 04:01:03 +0000 (UTC) Original-X-From: ding-owner+M667@lists.math.uh.edu Fri May 02 06:01:01 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19BRjI-0004nV-00 for ; Fri, 02 May 2003 06:01:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19BRk0-00043M-00; Thu, 01 May 2003 23:01:44 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19BRjw-00043H-00 for ding@lists.math.uh.edu; Thu, 01 May 2003 23:01:40 -0500 Original-Received: (qmail 7501 invoked by alias); 2 May 2003 04:01:39 -0000 Original-Received: (qmail 7496 invoked from network); 2 May 2003 04:01:39 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by sclp3.sclp.com with SMTP; 2 May 2003 04:01:39 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 19BRk4-0006Ax-00 for ; Fri, 02 May 2003 06:01:48 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 99 Original-NNTP-Posting-Host: 216.12.206.162 Original-X-Trace: quimby.gnus.org 1051848108 23742 216.12.206.162 (2 May 2003 04:01:48 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 2 May 2003 04:01:48 GMT User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:FqM4OCKK0v59PVt2ER6BiGJNlTo= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:52124 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:52124 Harry Putnam writes: > I've recently come back to using the agent after several mnths of > running plugged only. The current setup with undownloaded face seems > to overpower other long standing faces and options. > > When messages come in, they seem to receive a dull grey face > (normal-undownloaded) and unless one actuall downloads the message it > is not possible to change that face with other actions that normally > would change a message face. Things like ticked, domant, read etc > have no effect on this overpowering face. Well, it's all in the eye of the beholder. Several colors were tried before the group tired of seeing it changed or decided that they liked the green. To be honest, I'm not sure which. > That might make some sense if the user had true predicate in all > groups and never needed to keep track of undownloaded but read or > ticked but undownloaded or any number of other possibilities, one > might encounter while online. > > I haven't noticed any complaints about this so am wondering if it > might be some screw up in my local settings. > > Just at a quick thought, it seems the undownloaded face is more a > pain in the butt than a help. The agent isn't much use if you haven't downloaded an article. If you use gnus-agent-fetch-session (J s) then the undownloaded face may not be much of a help. However, if you like to pick and choose the articles to download, it helps with keeping track of your decisions. > Henrik Enberg writes: > >> Harry Putnam writes: >> >>> Is it a local problem or is it intended to work this way? If the >>> latter how would I override or disable this behavior? >> >> Customize gnus-summary-{low,high}-undownloaded-face. I agree that the >> default is a bit overwhelming. That will change the color. If you want to completely remove the undownloaded face (and thereby restore the behavior that you're comfortable with), do the following. Customize gnus-summary-highlight. Remove the three cons cells that reference the undownloaded faces. If you would prefer a text indicator, you can add the %O specification to gnus-summary-format-spec. > Maybe I'm not following you here. But first what determines a high > interest undownloaded or low interest undownloaded? Does it involve > scoring? (I don't use scoring) It uses scoring. > I did customize the normal-undownloaded but that has no bearing on the > real problem. That is, the faces associated with other marks are not > possible unless the article is downloaded. (read, ticked etc) The agent was largely designed from the perspective of the nntp backend. Since the retention times on many servers is fairly low, it really not safe to mark an article then expect it to still be available later. However, if you fetch it into the agent, you can then mark it knowing that it will always be available. > Does customizing low high somehow affect that problem?. > Are you able to mark undownloaded messages as read, ticked, dormant > etc and see a face change? > > Many of the groups under my agentized server are in default category > which I have predicated to false. I don't want to download them but > do want to read them online (plugged) and be allowed to have faces > associated with read, ticked, dormant etc be used. The fact that the > group is under an agentized server shouldn't break those faces. > > What I see is that in those default (false) category groups messages > will never be downloaded so all the normal gnus faces for read, > ticked etc are useless. Actually, 'never' is a little misleading. All that you've done is told Gnus that you don't want it to automatically fetch articles into the agent. The default category will not prevent you from using a much more sophisticated selection tool, your mind, to fetch interesting articles into the agent. > Surely this is not the intent of the > overpowering undownloaded face? We used to be able to have groups > only read online coexist with agentized groups and have no face > conflict. Now it appears that will only work if the groups are on > different servers, one agentize the other not. No, everything is customizable to the point that you can get back the exact non-agentized appearance. Kevin