From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/52316 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: Overbearing undownloaded face Date: Mon, 05 May 2003 10:08:03 -0500 Sender: ding-owner@lists.math.uh.edu Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1052148438 13142 80.91.224.249 (5 May 2003 15:27:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 5 May 2003 15:27:18 +0000 (UTC) Original-X-From: ding-owner+M859=ding+2Daccount=gmane.org@lists.math.uh.edu Mon May 05 17:27:11 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 19ChYV-0001ft-00 for ; Mon, 05 May 2003 17:07:04 +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 19ChZo-0000EX-04 for ding-account@gmane.org; Mon, 05 May 2003 10:08:24 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19ChZj-0000EQ-00 for ding@lists.math.uh.edu; Mon, 05 May 2003 10:08:19 -0500 Original-Received: (qmail 11641 invoked by alias); 5 May 2003 15:08:19 -0000 Original-Received: (qmail 11636 invoked from network); 5 May 2003 15:08:18 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by sclp3.sclp.com with SMTP; 5 May 2003 15:08:18 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 19ChbR-00023H-00 for ; Mon, 05 May 2003 17:10:05 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 74 Original-NNTP-Posting-Host: h-66-134-21-50.hstqtx02.covad.net Original-X-Trace: quimby.gnus.org 1052147405 7890 66.134.21.50 (5 May 2003 15:10:05 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 5 May 2003 15:10:05 GMT User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:issCnj9Bqn7doN+0VDLgFvXoJwc= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:52316 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:52316 Harry Putnam writes: > Simon Josefsson writes: > >> Hm. I must be missing some kind of use people make of the face. > > At one time I was a heavy user of the agent. I can tell you that it > can be confusing in a group that you read both on and off line. I > often had to back up and download a message that I had read on line > but never downloaded. Back then you couldn't tell. It just showed > read. (While online) So I can see some value in somekind of indicator. > that is present even when online. What I take issue with is again > related to reading both on and off line on the same server. FYI, I am working on a group parameter that will provide fine-grain control over which groups display the undownloaded faces. Aside from turning the faces on/off, the undownloaded faces will still function as they do now. > The undownloaded face server to show whether something is written to > disk or not, but I think it should not over shadow other usefull > marks one might want to use. So, I wonder if there is isn't some > other way to indicate downloadedness. Not use a face at all. Yes. Kai developed a format indicator at the same time that I worked on the face solution. > Kai says that is orthogonal thinking. Running at right angles I guess > he means, or talking apples and oranges. But can't we use something > in summary format line to indicate the downloadedness of an article > and just drop the undownloaded faces? > > As Kevin pointed out that last part can be done by removing the 3 > default cons cells pertaining to downloadedness at > gnus-summary-highlight. That returns you to pre downloaded face > behavior, which I favor. But since I see usefullness in knowing > downloadedness can't we do it another way that doesn't use an all > powerfull face? Now, you're coming closer to the problem. What you're seeing as arbitrary choices on my part are actually the result of constraints imposed by the existing framework. The summary format line, by virtue of being a string, makes it trivial to extend its capabilities. The downside is that 1) if I changed the default, I'd annoy everyone as even unagentized summary buffers would show a new column, and 2) those people who had already customized the format line would have to read the manual to discover the new feature. So, we have a new format but you have to go looking for it to take advantage of it. The face selection is handled by gnus-summary-highlight. It's an alist of conditions and face symbols. It functions just like the cond function. The first non-nil condition will select the face. This structure is rarely customized as you're specifying both the face and the precidence of faces. In my opinion, this mechanism needs to be rewritten. One of my first releases of the undownloaded face was just that, one face. A number of people were upset that undownloaded articles hid the score faces so I went back and created the high/low undownloade faces (3 faces total). Now, you would like to see a read/unread status (6 faces total), ticked/unticked (12 faces total), etc. (Aren't permutations fun :) ). This is an option, but one that makes it difficult for individuals to customize Gnus to a new color-scheme. What we need is a highlight structure that specifies face attributes (bold/italic/normal, red/green/blue, etc.) then matches on multiple conditions. Of course, we'd then need some sort of face engine to find/create a face for each combination of attributes. Anyone know of one? Kevin