Confused about crosspost marking behavior.

Confused about crosspost marking behavior.

[Rob Browning]

I recently changed my setup to split some incoming messages to
multiple groups (more on that in my second question), and, as
expected, I had a message that was posted both to my inbox and another
group.  When I read that message in my inbox, I went ahead and marked
it as expirable.  When I went to the other group to check on it, it
wasn't there, so I figured it had also been marked as expirable.  When
I checked by re-entering the group with "C-u Enter", I found that it
had actually been marked as read.  Now I wouldn't have been surprised
if it had either been marked the same as I marked it in the other
group, or if it had not been marked at all, but to be marked
differently both places was unexpected.  (Also, it might be nice to be
able to choose whether or not a given command affects just the current
article, or all instances of it...)

As additional information, I use Kai's general approach (I think) to
handling my mail groups.  All my groups are auto-expire, and I have it
set up so that the normal movement commands default to marking
articles expirable, not "read".

  ;; Make sure all groups are auto-expire.
  (setq gnus-auto-expirable-newsgroups "^nnml")

  ;; Use this for auto-expire only.
  (remove-hook 'gnus-mark-article-hook
               'gnus-summary-mark-read-and-unread-as-read)
  (add-hook 'gnus-mark-article-hook 'gnus-summary-mark-unread-as-read)

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

Re: Confused about crosspost marking behavior.

[Kai Großjohann]

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

> [...]  Now I wouldn't have been surprised if it had either been
> marked the same as I marked it in the other group, or if it had not
> been marked at all, but to be marked differently both places was
> unexpected.

Yes, that's a strange behavior of Gnus.  If you were to change from
auto-expire to total-expire, the behavior would be more dwim-like:
both messages would have been marked as read, which would have made
them expirable.

I wonder whether one can do interesting tricks with the current
behavior...

There is a problem, though: what should happen if the article is
cross-posted to several groups, and some of them are auto-expirable
and some of them aren't?

> (Also, it might be nice to be able to choose whether or not a given
> command affects just the current article, or all instances of it...)

Yes, that would be nice.  It's been discussed on this list before, but
AFAIK, nothing much came of it.

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: Confused about crosspost marking behavior.

[Rob Browning]

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

> Yes, that's a strange behavior of Gnus.  If you were to change from
> auto-expire to total-expire, the behavior would be more dwim-like:
> both messages would have been marked as read, which would have made
> them expirable.

Right.  If you're not using total-expire, this behavior means that
you're going to slowly accumulate a set of read articles that should
have been deleted in the crossposted groups.  This makes the "&"
split-fancy operatory less useful.

I'm really beginning to suspect that Gnus just really wants me to use
total-expire and get used to it.  Using the other approaches, although
nice in that I get an "extra mark", seems to keep causing me problems
when the default behavior doesn't do what I want because it's really
geared toward total-expiry.

> There is a problem, though: what should happen if the article is
> cross-posted to several groups, and some of them are auto-expirable
> and some of them aren't?

Right.  I just keep getting this feeling that the whole total/auto
expire process isn't quite right.  It seems awkward and confusing to
me.  I wonder if, with a few changes, we couldn't make it clearer.
How about this? (caveat: I don't know enough to know if it would be
way too complex to implement):

  1) Make the expire mark orthogonal to the other marks.  In other
     words, an article can be both read and expired (this eliminates
     the problems with auto-expire and adaptive-scoring since gnus
     wouldn't lose the read-ness info it needs).

  2) In total-expire and auto-expire groups, make the normal movement
     commands (the ones that would mark articles as read, killed,
     etc.) mark articles as both read (or whatever) *and* expired.
     Now total-expire and auto-expire are the same thing (and both are
     fast).  As a bonus, that means that we don't have to keep trying
     to explain which one people should use.

  3) In other groups, the normal movement commands would just mark
     articles as read, killed, or whatever.  The user can still
     add/remove the expired mark manually using 'E' (though there
     should also be a command to remove *just* the expired mark).

  4) Only articles with an expire marke will ever be expired after the
     expiry-wait period.

  5) Arrange it so that if you mark a crossposted article, then it
     gets the "equivalent mark" everywhere.  Equivalent means that in
     cases where you mark the article as read (including killed,
     etc.), then it also gets an expire mark in any total/auto-expire
     groups, but not in "normal" groups.  However, if you mark an
     article as expired, then it gets the expire mark everywhere.

  6) Add a variable nnmail-crosspost-mark-query that, if true, asks
     the user what to do when gnus is about to mark a crossposted
     article (or articles):

       Marking crossposted article as read.  Apply to all groups? [Y/n]
       Unmarking crossposted article.  Apply to all groups? [Y/n]
       Expiring crossposted article.  Apply to all groups? [Y/n]
       etc.

     If it turned out to be useful, there could also be "force"
     versions of the commands that don't ask, even if asking is "on".

Is this actually an improvement?  It seems clearer to me, but how
about to others?

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

Re: Confused about crosspost marking behavior.

[Dan Christensen]

Your ideas sound good to me.  One minor suggestion:

>   6) Add a variable nnmail-crosspost-mark-query that, if true, asks
>      the user what to do when gnus is about to mark a crossposted
>      article (or articles):

The could be nnmail-crosspost-mark, which could have values t, nil or
'query, meaning to always do it, never do it, or query the user.  

Dan

-- 
Dan Christensen
jdc@math.jhu.edu

Re: Confused about crosspost marking behavior.

[Sudish Joseph]

Rob Browning writes:
> Right.  If you're not using total-expire, this behavior means that
> you're going to slowly accumulate a set of read articles that should
> have been deleted in the crossposted groups.  This makes the "&"
> split-fancy operatory less useful.

Yes.  However, auto-expire is (used to be?) faster than total-expire
on group exit for very large nnml groups.  My workaround is to run
total-expire once in a while to catch crossposted stragglers like so:

;; do total-expiry on all groups
(defun sj/gnus-do-total-expire ()
  (interactive)
  (let ((gnus-total-expirable-newsgroups "."))
    (gnus-group-expire-all-groups)))

I set gnus-total-expirable-newsgroups to nil otherwise and use only
auto-expiry for normal use.

IMO it would be better to have crossposts marked as "E"xpirable in
auto-expired groups by default.  I don't see much need for the current 
behavior, so it's debatable whether this should necessarily be
configurable.

-- 
Sudish Joseph                                          MindSpring Enterprises

Re: Confused about crosspost marking behavior.

[Justin Sheehy]

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

> Right.  If you're not using total-expire, this behavior means that
> you're going to slowly accumulate a set of read articles that should
> have been deleted in the crossposted groups.  This makes the "&"
> split-fancy operatory less useful.
> 
> I'm really beginning to suspect that Gnus just really wants me to use
> total-expire and get used to it.

Sounds like a good idea to me.  :-)

I've actually always found auto-expire to seem like a very ugly concept
when compared to total-expire, but that may just be me.

I also haven't yet seen a situation where I thought it made more sense 
to use auto-expire than total-expire.

> Right.  I just keep getting this feeling that the whole total/auto
> expire process isn't quite right. 

Well, I think that combining them can lead to confusion, but just as
long as you only use one or the other it is pretty straightforward.

> How about this? 

>   1) Make the expire mark orthogonal to the other marks.  In other
>      words, an article can be both read and expired

Isn't this already the case?  From looking at my newsrc.eld, it seems
to be.  But then, that was simply from a one-time test.  I never think 
about the expirable mark in normal situations.  :-)

[snip rest of suggestions]

> Is this actually an improvement?  It seems clearer to me, but how
> about to others?

As I said before, I haven't yet seen the situation where auto-expire
really made much sense.  To me, the simplest answer is always just
'use total-expire, it makes sense'.  

-Justin

 

Re: Confused about crosspost marking behavior.

[Rob Browning]

Justin Sheehy <dworkin@ccs.neu.edu> writes:

> I also haven't yet seen a situation where I thought it made more
> sense to use auto-expire than total-expire.

The only reason was that I was hung up on being able to use the read
mark for something other than killing articles.  I wanted read
articles to stick around as "archive" material, but I think I can just
adjust my thinking and become happy with just ticked and dormant.

Actually, given one fairly minor enhancement, I don't think I'd need
auto-expire *or* total-expire.  If I just had the
gnus-summary-mark-same-subject where you could provide the mark for it
to use, I'd be happy.  I don't really want auto-expire since I don't
want all read marks to turn to expires, I just need a more
powerful/flexible way to assign expire marks when called for.

I wonder if this would be hard; and I wonder if Lars would have any
interest in a patch for this...

If I do decide to switch to total-expire, then all I have to do is
figure out the easiest way to go through an ungodly number of groups
and mark all the read articles as dormant before I make the switch.

Thanks for response.

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

Re: Confused about crosspost marking behavior.

[Rob Browning]

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

> Actually, given one fairly minor enhancement, I don't think I'd need
> auto-expire *or* total-expire.  If I just had the
> gnus-summary-mark-same-subject where you could provide the mark for it
> to use, I'd be happy.  I don't really want auto-expire since I don't
> want all read marks to turn to expires, I just need a more
> powerful/flexible way to assign expire marks when called for.

I quickly realized there already is a gnus-summary-mark-same-subject,
but it only allows a few marks.
 
> I wonder if this would be hard; and I wonder if Lars would have any
> interest in a patch for this...

Well, to follow myself up, here's an initial attempt.  I've never
messed with gnus programming before, so this might be fubar, violate
all kinds of conventions, or just be a bad idea...

I just mirrored the existing gnus-summary-mark-same-subject, but use a
symbol to represent the mark (which might be bad), and I treat
'expirable and 'dormant as "read style" marks.  I looked at the other
code, and this passed the smell-test, but I wasn't sure it was
*right*.  I haven't tested it either.  I wanted to see if I was on the
right track first.

(defun gnus-summary-mark-same-subject-with-mark (subject mark)
  "Mark articles with same SUBJECT with mark, which must be one of either 'read,
'ticked, 'unread, 'dormant, or 'expirable."

  (let ((count 1))
    (save-excursion
      (cond
       ((eq mark 'read)			; Mark as read.
	(while (and
		(progn
		  (gnus-summary-mark-article-as-read gnus-killed-mark)
		  (gnus-summary-show-thread) t)
		(gnus-summary-find-subject subject))
	  (setq count (1+ count))))
       ((eq mark 'ticked)		; Tick.
	(while (and
		(progn
		  (gnus-summary-mark-article-as-unread gnus-ticked-mark)
		  (gnus-summary-show-thread) t)
		(gnus-summary-find-subject subject))
	  (setq count (1+ count))))
       ((eq mark 'unread)		; Mark as unread.
	(while (and
		(progn
		  (gnus-summary-mark-article-as-unread gnus-unread-mark)
		  (gnus-summary-show-thread) t)
		(gnus-summary-find-subject subject))
	  (setq count (1+ count))))
       ((eq mark 'dormant)              ; Mark as dormant.
	(while (and
		(progn
		  (gnus-summary-mark-article-as-read gnus-dormant-mark)
		  (gnus-summary-show-thread) t)
		(gnus-summary-find-subject subject))
	  (setq count (1+ count))))
       ((eq mark 'expirable)            ; Mark as expirable.
	(while (and
		(progn
		  (gnus-summary-mark-article-as-read gnus-expirable-mark)
		  (gnus-summary-show-thread) t)
		(gnus-summary-find-subject subject))
	  (setq count (1+ count))))
       (t
        (error "Unknown mark: %s" mark)))
      (gnus-set-mode-line 'summary)
      ;; Return the number of marked articles.
      count)))

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

Re: Confused about crosspost marking behavior.

[David S. Goldberg]

Re: gnus-summary-mark-same-subject doesn't handle E

Why not just do a gnus-uu-mark-by-regexp (M P R) and provide the
subject you want marked.  That will process mark that subject so then
you can (M-& E) to mark all those articles with the expire mark (E
doesn't appear to honor the process mark itself).  That would also be
pretty easy to set up as a macro of simple function if you do it a
lot.  If you use threading, you can process mark an entire thread with
M P t (gnus-uu-mark-thread).
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: Confused about crosspost marking behavior.

[Rob Browning]

dsg@mitre.org (David S. Goldberg) writes:

> Why not just do a gnus-uu-mark-by-regexp (M P R) and provide the
> subject you want marked.  That will process mark that subject so then
> you can (M-& E) to mark all those articles with the expire mark (E
> doesn't appear to honor the process mark itself).  That would also be
> pretty easy to set up as a macro of simple function if you do it a
> lot.  If you use threading, you can process mark an entire thread with
> M P t (gnus-uu-mark-thread).

A macro might be OK.  In the end I want something quick like C-k since
I expect to be using it a lot, interleaved with C-k (the idea would be
that some threads I expire, some I mark read... -- presuming I'm not
using *-expire).

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

Re: Confused about crosspost marking behavior.

[Hrvoje Niksic]

Justin Sheehy <dworkin@ccs.neu.edu> writes:

> I also haven't yet seen a situation where I thought it made more
> sense to use auto-expire than total-expire.

Neither have I.  To me it seems that auto-expire is a historical relic
from the times when only auto-expire existed.  Some people claim that
to them auto-expire it seems "safer", because they can see which
articles are to be expired (typically all of them).

Re: Confused about crosspost marking behavior.

[Yair Friedman (Jerusalem)]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> Justin Sheehy <dworkin@ccs.neu.edu> writes:
> 
> > I also haven't yet seen a situation where I thought it made more
> > sense to use auto-expire than total-expire.
> 
> Neither have I.  To me it seems that auto-expire is a historical relic
> from the times when only auto-expire existed.  Some people claim that
> to them auto-expire it seems "safer", because they can see which
> articles are to be expired (typically all of them).

I use auto-expire and quite happy about it, there are some groups which
contain email that is relevant only for few days together with messages
that have longer lifetime.  The short-living mails are auto-expired
while the other are archive when the group become too full.

Re: Confused about crosspost marking behavior.

[Rob Browning]

What's the behavior of 'B del' (gnus-summary-delete-article) with
respect to crossposts?  I suppose I could use that to just kill a
redundant copy in my inbox that I was finished with without disturbing
the one in the other group(s)...

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

Re: Confused about crosspost marking behavior.

[Lars Magne Ingebrigtsen]

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

> What's the behavior of 'B del' (gnus-summary-delete-article) with
> respect to crossposts?  I suppose I could use that to just kill a
> redundant copy in my inbox that I was finished with without disturbing
> the one in the other group(s)...

You suppose right.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen