Re: Trying to document some of gnus' darkish corners -- please help.

[Rob Browning <rlb@cs.utexas.edu>]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I don't know, but it is reasonable not to expect Gnus to do so, since
> `spooling' is what happens when Gnus retrieves messages from /var/mail
> or the POP server (or wherever).  And obviously, messages don't have
> any marks there.

Yes, unfortunately it was *after* I had done it, I recalled that this
was probably the case.

> Maybe you really wanted to move the messages?  That preserves marks.
> There is a variable gnus-move-split-methods which is similar to
> nnmail-split-methods but suggests default groups to move to when
> doing `B m'.

Yes, but I was respolling 4800 messages because I was breaking up a
group that used to have a number of mailing lists dumped into it into
separate groups for each, and I *definitely* didn't want to loose my
marks.

So having default suggestions 4800 times wouldn't be all that helpful
:> As people get more sophisticated with gnus, it seems reasonable to
expect that they might want to go back and "re-work" their config as I
described, splitting up groups, etc.  For this case, it would be
really nice to have some other command that's essentially the same as
respool, except that it preserves the marks, though I have no idea how
hard that would be to implement.

Also, is moving (B m) and copying guaranteed to preserve marks, and
what about (B del), does that one affect other cross-posted articles,
marking them as read too?  I guess I'll have to do some
experimentation, but in then end I'd really like to get this
documented so it's "official behavior".

> >   2) When you mark a crossposted article, what's supposed to happen to
> >      the other copies?
> 
> Yes, this is a painful situation.  When you read a crossposted
> article, the other instances are marked as read.  Apparently, marking
> an article as expirable counts as `reading' it.

Yep.  Now that I think back, I recall looking at the code, and I think
I recall that there was only one function called to handle the
marking, and it just called a "mark as read" function which even
ignored the setting of auto-expiry for the group in question.  That's
my recollection anyhow.
 
> A couple of years ago (I think) we discussed whether it would be
> useful to make the marking behavior of Gnus more orthogonal and
> predictable.

This would be *GREAT*, but I doubt it's going to happen anytime soon,
and I'm not in a position to fix it, so what I'd really like to do is
gather as much information as I can about the way things *are*, and
make sure that's readily available so that others are less likely to
fall into the cracks that I did.

> The idea was that there should be commands to apply a mark to the
> current instance only, and other commands to apply a mark to all
> instances, and maybe commands that do what they do now.

Frankly, if it's possible to implement efficiently, I'd love to see a
system where the idea of a fixed set of marks is juked altogether and
we just go to a system where each article can have a set of tags
(symbols) associated with it.

Then gnus would have a reserved set of symbols for the things it's
doing now (gnus-read, gnus-dormant, gnus-unticked, etc. -- say
anything that starts with gnus- is reserved for internal use), and all
of the current processes just become functions that traverse articles
checking for certain tags and taking appropriate actions.  Users, and
add on packages, would be allowed to add their own tags too and could
tell gnus how to handle them.  This would immediately let me solve my
"I need at least one more state in addition to ticked and dormant"
problem that I've prattled on about off and on for a while now...

Given the "tags" setup, it would then be nice to have hooks like an
article marked hook where you could define a function that was given
the article, the cross-posted articles, and the old and new marks as
arguments and then you could do what you wanted to the crossposts.
There could also be some default hook functions available that handled
things in the most common ways.

> I think that especially the `apply this mark to all copies' commands
> could be really useful.

> As it is, I don't use cross posts.

I guess I'm about to quit, but it's a shame that something that might
be so useful, and *is* so useful for news is more or less, from my
perspective, useless for mail.

The reason I switched on crossposting in the first place was that I'm
on *very* high volume lists, and now and then, without cross-posting,
people would send something urgent to me and to the list, that would
only get filed to the list, and I wouldn't see it for
way-too-long(TM).  This was bad.  I suppose that instead of
crossposting, I could fix thisby either:

  1) Turning off gnus-use-cross-reference, but this would make me
     loose this for news as well, which is arguably not what I'd want.

  2) Continue to cross-post, but just use (B del) to kill the article
     in my inbox and then deal with it in the other group.  This
     presumes that (B del) doesn't mess with crossposted marks.

  3) Turning off all cross-posting in my split-method and just file
     things that are to me and a list to my inbox first, so I'll see
     it, and then I'll just have to re-file it by hand (this seems the
     best for now)...

Thanks for the help.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930