Gnus development mailing list
 help / color / mirror / Atom feed
* Soups and marks
@ 1996-06-16 17:48 Kai Grossjohann
  1996-06-17  2:22 ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 4+ messages in thread
From: Kai Grossjohann @ 1996-06-16 17:48 UTC (permalink / raw)


Hi all,

I have begun to brew soups.  While this is rather nice, I do have one
minor problem.  When brewing a soup, Gnus by default marks all souped
articles as read.  I would like to have control over the articles that
will be deleted, however (often I want to keep souped articles), and
as I use total-expire, marking them as read is not quite what I want.

I have therefore set gnus-souped-mark to ?\? (dormant) which works
rather nicely, mostly.  However, I have found out that I have to
retrieve all of a group in order to see the dormant articles.  Is
there a better way?

I know that acutally, the articles are marked ?F, but it seems that
Gnus thinks these are read, as well, when I reenter a group after
brewing soups.

I have also tried ?\  (unread), but that didn't allow me to
distinguish between unread articles that have already been souped and
those that haven't.

I can't use ?! as I use that for articles where I know I want to keep
them.  (For souped articles, I don't know yet.)  Wouldn't be able to
distinguish between souped and other articles there, either.

Can anyone give me a hand here?  Should I convert to auto-expire
rather than total-expire in order to have the `read' mark left over
for such things?

Thanks in advance for any hint you might be able to give.
kai
-- 
Life is hard and then you die.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Soups and marks
  1996-06-16 17:48 Soups and marks Kai Grossjohann
@ 1996-06-17  2:22 ` Lars Magne Ingebrigtsen
  1996-06-17 14:01   ` Kai Grossjohann
  0 siblings, 1 reply; 4+ messages in thread
From: Lars Magne Ingebrigtsen @ 1996-06-17  2:22 UTC (permalink / raw)


Kai Grossjohann <grossjoh@ls6.informatik.uni-dortmund.de> writes:

> I have begun to brew soups.  While this is rather nice, I do have one
> minor problem.  When brewing a soup, Gnus by default marks all souped
> articles as read.  I would like to have control over the articles that
> will be deleted, however (often I want to keep souped articles), and
> as I use total-expire, marking them as read is not quite what I want.

Well, they will probably be read, so marking them as such is probably
the most sensible thing.

> I have therefore set gnus-souped-mark to ?\? (dormant) which works
> rather nicely, mostly.  However, I have found out that I have to
> retrieve all of a group in order to see the dormant articles. 

`/ D' will display all dormant articles in the current group.

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Soups and marks
  1996-06-17  2:22 ` Lars Magne Ingebrigtsen
@ 1996-06-17 14:01   ` Kai Grossjohann
  1996-06-17 16:20     ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 4+ messages in thread
From: Kai Grossjohann @ 1996-06-17 14:01 UTC (permalink / raw)
  Cc: ding

>>>>> Kai Grossjohann <grossjoh@ls6.informatik.uni-dortmund.de>
>>>>> writes:

  Kai> [...] When brewing a soup, Gnus by default marks all souped
  Kai> articles as read. [...]

>>>>> On 17 Jun 1996 04:22:32 +0200, Lars Magne Ingebrigtsen
>>>>> <larsi@ifi.uio.no> said:

  Lars> Well, they will probably be read, so marking them as such is
  Lars> probably the most sensible thing.

Yes.  No.  I argue as follows:

Usually there two kinds of `read' messages: those that you want to
delete and those that you want to keep.  Without total-expire, the
ones to delete are the `expirable' ones, the ones to keep the `read'
ones.  With total-expire, the ones to delete are the `read' ones
whereas the ones to keep will be `ticked' or `dormant' (I suppose).

In both cases you have two kinds of messages but with your process
they're both marked the same way.  --> Conflict.

My suggestion was to mark them specially so that the user can look at
them and assign the correct mark intellectually.  (If you can't
program it, let the user do it.)

But your suggestion of taking note of the unread messages is really
nice and could rather simply be adapted to save all marks, I guess.  I
think I'll be doing this, in fact.

kai
-- 
Life is hard and then you die.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Soups and marks
  1996-06-17 14:01   ` Kai Grossjohann
@ 1996-06-17 16:20     ` Lars Magne Ingebrigtsen
  0 siblings, 0 replies; 4+ messages in thread
From: Lars Magne Ingebrigtsen @ 1996-06-17 16:20 UTC (permalink / raw)


Kai Grossjohann <grossjoh@ls6.informatik.uni-dortmund.de> writes:

> Usually there two kinds of `read' messages: those that you want to
> delete and those that you want to keep.  Without total-expire, the
> ones to delete are the `expirable' ones, the ones to keep the `read'
> ones.  With total-expire, the ones to delete are the `read' ones
> whereas the ones to keep will be `ticked' or `dormant' (I suppose).

Yes, but SOUPing always assumes that you want to delete the messages.
(Which might be a faulty assumption.)  If the group is auto-expirable,
the articles are marked as expirable; if it's a total-expirable group,
the articles are marked as read.  Since the user takes a copy of the
articles when SOUPing, that seems like the most reasonable default
action to take.

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1996-06-17 16:20 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-06-16 17:48 Soups and marks Kai Grossjohann
1996-06-17  2:22 ` Lars Magne Ingebrigtsen
1996-06-17 14:01   ` Kai Grossjohann
1996-06-17 16:20     ` Lars Magne Ingebrigtsen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).