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

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

[Rob Browning]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.gnus as well.


(If it's impolite to post this issue to both the newsgroup and the
 ding list, then just let me know and I'll be more careful in the
 future, but I suspected the audiences were different and that both
 might be interested and able to help.)

I've had a fairly painful set of experiences with gnus over the past
few years where what I thought it was going to do, and what it did
were two different things.  To some extent, this was my fault for
assuming that things would actually work the way that I considered
reasonable, but to some extent, I think clearer docs would have saved
me.

As a result, I'm interested in trying to figure out what the current
state of affairs is with respect to a few issues, and to help
(re)write some info docs to clear these things up.  Along those lines,
I'd like to see who knows the answers to any or all of the following
questions.  Please try and be careful to either make sure you're sure
you're right, or just make it clear that you're not sure.  Some of the
problems I've had in the past came from people making suggestions that
sounded like they should have worked, but actually didn't because Gnus
hadn't quite fully implemented X or Y feature that interacted badly
with the change they suggested.  I'm happy to double check things as
long as I know I need to.

I'd also like to answer these questions just because it'll make it
clearer what the overall intent/design of the current architecture is.

  1) Is gnus supposed to preserve article marks across backend
     respools (B r)?  If not, why not, and also if not, then might it
     make sense to add a separate command that *will* preserve the
     marks?  (I just lost about 1400 marks because I forgot that gnus
     would clobber them in this situation -- kinda painful).

  2) When you mark a crossposted article, what's supposed to happen to
     the other copies?  I had assumed that when you marked a
     crossposted article, either all of the copies would get the same
     mark, or copies other than the one being directly marked would be
     left alone.  Neither seems to be the case.  Right now it seems
     that at least in some cases, the article you mark gets the mark
     you indicate, and the crossposted copies get a different mark (in
     my experience the copies are marked as read).  This seems worse
     than either of the two alternatives I mention above, though
     perhaps I'm missing something.

     The reason I noticed this is because I used to use the default
     expire mechanism (where you have to mark articles with 'E' to
     expire them) and then, at someone's suggestion, I turned on
     crossposting.  When I went to expire large numbers of crossposted
     articles, I just assumed that the other copies would either get
     expired or left alone (so that I'd have to expire them directly
     later).  What actually happened was that the other copies were
     just marked as read, not expired, and they sat around on disk
     until I noticed that my partition was filling up, and made me
     suspicious enough to investigate.

     Of course this is also potientially dangerous if you don't know
     about it and you're using total-expire.  Say you mark a
     crossposted article as urgent or dormant, and now it gets marked
     as read elsewhere which means it'll get deleted.  If this isn't
     what you expected, it could be bad.  So do the copies get marked
     as read?  Should they?  (I'll have to test this one and see.)

     I'm not sure what I'd like to see ideally, but it might be nice
     to have a flag you can set (or a separate command) that would
     have it just ask you what mark to give the crossposted copies
     when it notices that the article is crossposted.  I'm not sure
     that's feasible though.

     Alternately, I think either using the same mark everywhere, or
     not marking the copies at all, might be better, but as I said,
     perhaps I'm missing the justification for the current behavior.

These are the two main issues I've got right now.  It's not so much
that I want the behaviors changed, though that might be appropriate.
More importantly, I just want a clear understanding, and clear
documentation, of the status-quo so that I don't keep shooting myself
in the foot.

Thanks for any help.

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

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

[Kai Großjohann]

Rob Browning <rlb@cs.utexas.edu> writes:

>   1) Is gnus supposed to preserve article marks across backend
>      respools (B r)?  If not, why not, and also if not, then might it
>      make sense to add a separate command that *will* preserve the
>      marks?  (I just lost about 1400 marks because I forgot that gnus
>      would clobber them in this situation -- kinda painful).

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.

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

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

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

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.

kai
-- 
Beware of flying birch trees.

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

[Alan Shutko]

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.

Spooling is also advertised as an easy way of moving articles around,
or compacting mail groups.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
182 days, 23 hours, 7 minutes, 6 seconds till we run away.
DM Advice:  Every tavern scene should end in a brawl.

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

[Rob Browning]

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