Red gnus feature request - user defined marks.

Red gnus feature request - user defined marks.

[Yair Friedman]

I usually tick articles (!) for various reasons, it would be
comfortable to visually differentiate between the reasons, for gnus
they are all ticked but in the summary the should look different.

Is it possible to get this effect in sgnus?

--
Yair. 

Re: Red gnus feature request - user defined marks.

[Lars Magne Ingebrigtsen]

Yair Friedman <yair@cs.huji.ac.il> writes:

> I usually tick articles (!) for various reasons, it would be
> comfortable to visually differentiate between the reasons, for gnus
> they are all ticked but in the summary the should look different.
> 
> Is it possible to get this effect in sgnus?

No.  What you'd want is being able to annotate a message, I guess.
Annotations could then visually be shown in various ways.  I've added
this to the Red Gnus todo list.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Red gnus feature request - user defined marks.

[Per Abrahamsen]

>>>>> "YF" == Yair Friedman <yair@cs.huji.ac.il> writes:

YF> I usually tick articles (!) for various reasons, it would be
YF> comfortable to visually differentiate between the reasons, for gnus
YF> they are all ticked but in the summary the should look different.
YF> 
YF> Is it possible to get this effect in sgnus?

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

LMI> No.  What you'd want is being able to annotate a message, I guess.
LMI> Annotations could then visually be shown in various ways.  I've added
LMI> this to the Red Gnus todo list.

I think the best way to do that would be to use labels, preferable in
a way that is compatible with how RMAIL and VM use labels, at least
for mail groups.  This would also make it easier to switch from RMAIL
to Gnus, as the user wouldn't lose all his carefully entered labels.

I think you decided to drop labels in when writting (ding) Gnus since
labels could, to some degree, be simulated by having multiple groups
combined into a single virtual group.  However, using labels is more
light weight than moving articles to separate groups, and labels could
work really well together with limits.

Re: Red gnus feature request - user defined marks.

[John Griffith]

Per Abrahamsen writes:
>I think the best way to do that would be to use labels, preferable in
>a way that is compatible with how RMAIL and VM use labels, at least
>for mail groups.  This would also make it easier to switch from RMAIL
>to Gnus, as the user wouldn't lose all his carefully entered labels.

For the same reasons, it would be nice if GNUS could understand
and manipulate mh sequence files.

Re: Red gnus feature request - user defined marks.

[Lars Magne Ingebrigtsen]

John Griffith <griffith@sfs.nphil.uni-tuebingen.de> writes:

> For the same reasons, it would be nice if GNUS could understand
> and manipulate mh sequence files.

Well, I don't know.  Gnus is a news reader, not a mail reader.  :-)

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Red gnus feature request - user defined marks.

[Stephen Peters]

larsi@ifi.uio.no (Lars Magne Ingebrigtsen) writes:
>John Griffith <griffith@sfs.nphil.uni-tuebingen.de> writes:
>
>> For the same reasons, it would be nice if GNUS could understand
>> and manipulate mh sequence files.
>
>Well, I don't know.  Gnus is a news reader, not a mail reader.  :-)

Not a mail reader?  That's news to me.  
[double entendre left in as a public service].

-- 
Stephen L. Peters                         speters%samsun@us.oracle.com
 For PGP key, use keyservers or send email with subject: SEND PGP KEY
      PGP fingerprint: BFA4 D0CF 8925 08AE  0CA5 CCDD 343D 6AC6
	Oracle won't speak for me, so I won't speak for them.

Re: Red gnus feature request - user defined marks.

[Lars Magne Ingebrigtsen]

abraham@dina.kvl.dk (Per Abrahamsen) writes:

> LMI> No.  What you'd want is being able to annotate a message, I guess.
> LMI> Annotations could then visually be shown in various ways.  I've added
> LMI> this to the Red Gnus todo list.
> 
> I think the best way to do that would be to use labels, preferable in
> a way that is compatible with how RMAIL and VM use labels, at least
> for mail groups.  This would also make it easier to switch from RMAIL
> to Gnus, as the user wouldn't lose all his carefully entered labels.

What do RMAIL and VM labels look like?  

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Red gnus feature request - user defined marks.

[Per Abrahamsen]

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

LMI> What do RMAIL and VM labels look like?  

RMAIL labels are defined in the file etc/BABYL in the emacs
distribution. 

I think VM extended the unix mbox format to support labels, but I
don't know the syntax.

Re: Red gnus feature request - user defined marks.

[Lars Magne Ingebrigtsen]

abraham@dina.kvl.dk (Per Abrahamsen) writes:

> RMAIL labels are defined in the file etc/BABYL in the emacs
> distribution. 

Aha -- those are the funky 

1, answered,, zval, bug,

lines.  Well, nnbabyl could alter the group info to heed labels like
answered and read, I guess.  What I was thinking of was a more general
annotation functionality.  The user taps some key, enters a random
string -- "I've really got to think hard on this one", and this
annotation will then be presented in some way associated with the
message itself.

Perhaps not, though.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Red gnus feature request - user defined marks.

[Per Abrahamsen]

>>>>> "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.

Re: Red gnus feature request - user defined marks.

[Kai Grossjohann]

>>>>> "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.  

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

I propose that we have labels first.  Annotations can be somewhat
imitated by editing the message, can't they?

Or, maybe we would like to implement annotations by editing the
message?  And automatically add a label?

Using a header X-Annotated which contains the annotation?

        kai
--
~/.signature

Re: Red gnus feature request - user defined marks.

[Lars Magne Ingebrigtsen]

abraham@dina.kvl.dk (Per Abrahamsen) writes:

> 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'. 

I've now added this to the ever-growing Red Gnus todo list.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen