From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/5414
Path: main.gmane.org!not-for-mail
From: abraham@dina.kvl.dk (Per Abrahamsen)
Newsgroups: gmane.emacs.gnus.general
Subject: Re: Red gnus feature request - user defined marks.
Date: 01 Mar 1996 23:24:15 +0100
Organization: The Church of Emacs
Sender: abraham@dina.kvl.dk
Message-ID: <rj4ts8cv00.fsf@ssv4.dina.kvl.dk>
References: <199602271703.TAA19920@mangal.cs.huji.ac.il>
	<w8ska186il6.fsf@eistla.ifi.uio.no> <rj4tsbeo1w.fsf@ssv4.dina.kvl.dk>
	<w8slolmcxuu.fsf_-_@eistla.ifi.uio.no>
	<rjka16crbr.fsf@ssv4.dina.kvl.dk> <w8s68cpyyk2.fsf@eistla.ifi.uio.no>
NNTP-Posting-Host: coloc-standby.netfonds.no
X-Trace: main.gmane.org 1035146020 32733 80.91.224.250 (20 Oct 2002 20:33:40 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Sun, 20 Oct 2002 20:33:40 +0000 (UTC)
Return-Path: ding-request@ifi.uio.no
Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.3/8.6.9) with SMTP id PAA25068 for <steve@miranova.com>; Fri, 1 Mar 1996 15:08:48 -0800
Original-Received: from elc1.dina.kvl.dk (elc1.dina.kvl.dk [130.225.40.228]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <XAA15108@ifi.uio.no> for <ding@ifi.uio.no> ; Fri, 1 Mar 1996 23:26:07 +0100
Original-Received: from ssv4.dina.kvl.dk (ssv4.dina.kvl.dk [130.225.40.223]) by elc1.dina.kvl.dk (8.6.12/8.6.4) with ESMTP id XAA03150; Fri, 1 Mar 1996 23:20:34 +0100
Original-Received: (abraham@localhost) by ssv4.dina.kvl.dk (8.6.12/8.6.4) id XAA22346; Fri, 1 Mar 1996 23:24:16 +0100
X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM<U{B+4e{k79.Ya{~':DblFPCg$
 @60,BfLv2@SKZ19cMWK0/C'v;tM:|6B'R}U1rp6CL&kN({9<zF/V{:JCg27yC)9oZjeqcQawzKfiNL
 t9}`vjmK["dRQC/qGFQq"%u|Q`:6{"Rz}b(dnl_"3$Jtqimi>|8MBp/
Original-To: ding@ifi.uio.no
In-Reply-To: larsi@ifi.uio.no's message of 01 Mar 1996 10:04:13 +0100
Original-Lines: 40
Xref: main.gmane.org gmane.emacs.gnus.general:5414
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:5414


>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> Well, nnbabyl could alter the group info to heed labels like
LMI> answered and read, I guess.  

It could also keep them updated (the same for the Status: header of
unix mbox files).

They could be used like this:

`M l <name> RET' add label <name> to current message.
`M u <name> RET' remove label <name> from current message.
`/ l <expr> RET' limit summary buffer according to <expr>.

<expr> would be a boolean expression on the labels, e.g. 

	`/ l bug & !fixed RET'

would show all the messages which are labeled `bug' but not labeled
`fixed'. 

One could also immagine the labels being used for highliting, or
affect the summary line format.

LMI> What I was thinking of was a more general
LMI> annotation functionality.  The user taps some key, enters a random
LMI> string -- "I've really got to think hard on this one", and this
LMI> annotation will then be presented in some way associated with the
LMI> message itself.

I could see how this could be useful.  Annotations could be indicated
with a special mark in the summary line.  The annotations themself
could be stored in a hierarchy similar to the `cache' hierarchy.  It
doesn't sound overly complicated. 

I'd would probably use this to store annotations like

	This was resolved by phone.  The luser had forgotten to plug
	in the monitor.