From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/39898 Path: main.gmane.org!not-for-mail From: Harry Putnam Newsgroups: gmane.emacs.gnus.general Subject: Re: Display something besides Subject line on request Date: Fri, 02 Nov 2001 17:53:59 -0800 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035175535 30404 80.91.224.250 (21 Oct 2002 04:45:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:45:35 +0000 (UTC) Return-Path: Original-Received: (qmail 19315 invoked from network); 3 Nov 2001 01:56:43 -0000 Original-Received: from malifon.math.uh.edu (mail@129.7.128.13) by mastaler.com with SMTP; 3 Nov 2001 01:56:43 -0000 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 15zq2a-0001vw-00; Fri, 02 Nov 2001 19:56:08 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 02 Nov 2001 19:55:48 -0600 (CST) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id TAA00036 for ; Fri, 2 Nov 2001 19:55:35 -0600 (CST) Original-Received: (qmail 19304 invoked by alias); 3 Nov 2001 01:55:48 -0000 Original-Received: (qmail 19299 invoked from network); 3 Nov 2001 01:55:48 -0000 Original-Received: from smtp.newsguy.com (HELO newsguy.com) (209.155.56.71) by gnus.org with SMTP; 3 Nov 2001 01:55:48 -0000 Original-Received: from reader.local.lan (adsl-66.51.210.228.dslextreme.com [66.51.210.228]) by newsguy.com (8.9.1a/8.9.1) with ESMTP id RAA14156 for ; Fri, 2 Nov 2001 17:55:21 -0800 (PST) Original-Received: (from reader@localhost) by reader.local.lan (8.11.6/8.11.6) id fA31tLb03245; Fri, 2 Nov 2001 17:55:21 -0800 X-Authentication-Warning: reader.local.lan: reader set sender to reader@newsguy.com using -f Original-To: ding@gnus.org In-Reply-To: (prj@po.cwru.edu's message of "Fri, 02 Nov 2001 16:37:54 -0500") User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i586-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Original-Lines: 123 Xref: main.gmane.org gmane.emacs.gnus.general:39898 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:39898 prj@po.cwru.edu (Paul Jarc) writes: [...] >> Over time that would probably be faster since it would lack the >> overhead of having to find and keep another field in .overview. It >> would only happen on demand. > > Hm, maybe. More generally, we occasionally want to operate on > information which is normally not of interest, and thus not stored > with the NOV data - so it should be possible to do that without too > much trouble. OTOH, when the information we want to operate on is > stored with the NOV data, we shouldn't have to pay the penalty of > rescanning the original message header; that should be done only when What I'm describing falls more in your first point there I think. If I had said `X-Harry's special annotation once in a blue moon' It would be clearer. I actually would use it much more than that but still not enough to add overhead to nov generation. I used the extra header Keywords and Message-id for many mnths, finally dropping the keywords because I didn't use it that much. However confined to specific groups like groups where I might edit (add keywords) to articles frequently. So I still think this kind of usage would benefit from not requiring nov data to work. But like you say it should recognize if the data is available and use it if so. ShengHuo ZHU writes: > Try Ahh cool .. thanks > [...] > >> At this point I want that limited buffer to display the Keywords >> header instead of the Subject header. >> When I pop that limit I want the Subject back. Either by >> M-x or by hooking into the limiting some how. >> I guess M-x is the more reasonable. >> One could say M-x to toggle Keywords and M-x >> again to go back to Subject. > You can write a user-defined spec function with a switch variable, and > write another function to toggle the variable and update the summary > lines. This sounds like what I'm after. You make it sound easy... If I only had a brain. >> Further the Keywords line I may have added by gnus-edit-article will >> not be in the nov file. Unless I've run nnml-generate-nov... after >> adding it and have code in .gnus to include keywords in the nov file. >> This I also know how to do, but its not really what is necessary to get >> the results described above. Or at least not a very practicle way. > > The NOV updating code is in nnml.el and works for me. And also after > you g-e-a, the summary line is updated. What are the values of your > gnus-extra-headers and nnmail-extra-headers? Ohh cool... I wouldn't have seen that because I removed `keywords' some time ago. I am not having a problem understanding how to get keywords into nov or to have it displayed in an open article as one of visible headers. But I didn't know about the update mechanism ... that is nifty. My ambition here is as you've described, a switchable variable for summary format line that can be toggled at will. Do you think that would be mainline, usefull enough thing to be part of gnus? Those two variables both say (To Newsgroups). At one time I did have keywords there. But I notice entering large groups is really slow so I dropped it. I'm not really sure it helped though. Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes: > Harry Putnam writes: > >> At this point I want that limited buffer to display the Keywords >> header instead of the Subject header. > > Whee. Maybe it's easiest to make a %k entry in > gnus-summary-line-format-alist which shows the Keywords header, and > then you write a little function which limits, changes > gnus-summary-line-format to include %k instead of %f, and then a > similar function which pops the limit and sets > gnus-summary-line-format back. Yeah.. this sounds a lot like what ShengHuo suggested. > Ick. Why ick? Too Kludgy? > Is there a way to find out if the current summary is limited and what > that limit is? It might be as well to switch the whole group on and off. Except in a real large group that would be a time killer. > Then Harry could write a function which does like %f unless the > current summary buffer is limited based on Keywords. Yeah yeah .. thats the ticket. > Harry, do you know that you can use `/ x' to limit based on extra > headers? You could add Keywords to gnus-extra-headers and > nnmail-extra-headers. Then you don't need the `& Keywords ...' thing. Yeah, I know about that but as I said I dropped the extra Keywords header a while back. So if I added it back `/ x' would come into play. Its cleaner and quicker with fewer steps. I probably should just keep `Keywords' in there. I don't see a lot of improvement on opening groups anyway. The advantage of `& REGEXP', I think, is that you could search for any header, not just ones in NOV, by using the `body' target. You might get a false hit once in while where someone has included some header in the body but it would'nt be a big factor I don't think. Using `& Body' target ` REGEXP' allows you to do cool things like specify: `^User-Agent: [^G]' To catch any one cheating.. or `^Received:.*[dorky.tw.spammer.IP]' To immediately find and delete all that guff that shows up on the Texi list... he he.