From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/14575 Path: main.gmane.org!not-for-mail From: Harry Putnam Newsgroups: gmane.emacs.gnus.general Subject: requested changes / are these difficult? Date: 13 Mar 1998 18:11:42 -0800 Organization: none Sender: owner-ding@hpc.uh.edu Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035153745 16993 80.91.224.250 (20 Oct 2002 22:42:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 22:42:25 +0000 (UTC) Return-Path: Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by altair.xemacs.org (8.8.8/8.8.8) with ESMTP id SAA07136 for ; Fri, 13 Mar 1998 18:20:17 -0800 Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by xemacs.org (8.8.5/8.8.5) with ESMTP id UAA08193 for ; Fri, 13 Mar 1998 20:15:01 -0600 (CST) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id UAN10911; Fri, 13 Mar 1998 20:50:15 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 13 Mar 1998 20:13:58 -0600 (CST) Original-Received: from claymore.vcinet.com (claymore.vcinet.com [208.205.12.23]) by sina.hpc.uh.edu (8.7.3/8.7.3) with SMTP id UAA20181 for ; Fri, 13 Mar 1998 20:13:50 -0600 (CST) Original-Received: (qmail 7870 invoked by uid 504); 14 Mar 1998 02:13:40 -0000 Original-Received: (qmail 7867 invoked from network); 14 Mar 1998 02:13:39 -0000 Original-Received: from sunsite.auc.dk (130.225.51.30) by claymore.vcinet.com with SMTP; 14 Mar 1998 02:13:39 -0000 Original-Received: (qmail 5508 invoked by uid 509); 14 Mar 1998 02:13:32 -0000 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: emacs.ding Original-Lines: 75 Original-NNTP-Posting-Host: pm5-15.sba1.avtel.net Original-X-Trace: sunsite.auc.dk 889841611 5505 (None) 207.71.222.15 Original-X-Complaints-To: news@sunsite.auc.dk X-Newsreader: Gnus v5.6.2/Emacs 20.2 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:14575 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:14575 It seems that scoring works on a whole group at once. That is, you cannot limit the view one way or another and score just that view. Some kinds of scoring (on head and body) are currently not allowed in agent mode (unplugged). Can that be changed with out major revamping? These suggestions would only work well in agent mode with the articles being manipulated already stored on disk. A further stipulation would be that this kind of scoring could be done off line. And not really be connected to the current scoring calls. If scoring could be aimed at a 'limited' view, or at least only the articles present when an is done on a group, then the usefulness of limited views would increase 10 fold. (actually it would theoretically increase infinitely - but 10 fold is a good start) : ) You could limit the view to anything scorable by using the ' / v' . I think this would be quite an advantage. This would be a temporary scoring not initiated when a group is opened like the current scoring does. But something that could be invoked by the user when in a group. And would not use the current score file but a temp. file created for each session, if desired. Once this temp file was called up, all the score writing commands would apply to it. Apply a similar mechanism as re-search-forward to the scoring of 'body' or 'head' strings. Currently those kinds of scoring are not possible unplugged. All this would add up to a way to have a limited view of a regexp search on the body, or an arbitrary header. These functions are already possible when plugged. The biggest problem is that scoring is carried out on-line even if the articles showing are cached. Consequently, scoring on the body is brutally slow. Being illiterate with lisp and most other things pertaining to computing, make me imminently *un*qualified to know if this line of reasoning is barking up the wrong tree, so somebody stop me if it is off base. Here briefly is how I envisage using such a setup: Enter a group (comp.unix.wizardlike.commands), by-pass the groups '.SCORE' file. Run an empty .TEMP score file with V R to reduce all scores to 0. Pick a subject you are craving to know all about. In this case, you've forgotten the unix 'find' commmand that allows you to run 'find' in such a way that it tears through your disk and finds every last instance in every common file where people are instructed to forcibly pour milk down the throats of there pets. You remember it has the characters {} in it. Use the 'I' (increase) pick 'b'= body, type of search p=regexp (no permanence choice will come up in this scheme) At the 'raise:' prompt we insert: 'find.* [{}]' The scoring tears through the 800 articles showing, and elevates about 50 of them. You think hard and remember the word 'grep' should be in there so now limit the view to the first scored articles (50), and run another higher score where you enter 'find.*grep.* [{}]' Sure enough, this turns up several examples where you are able to construct a command: find / type -f -exec grep 'milk' -il {}\; Finally rerun the real .SCORE file or just wait till you open the group again and it happens anyway. Of course, uses may vary. : ) -- Harry Putnam reader@newsguy.com