* Trying to document some of gnus' darkish corners -- please help. @ 2000-05-11 22:43 Rob Browning 2000-05-12 15:58 ` Kai Großjohann 0 siblings, 1 reply; 4+ messages in thread From: Rob Browning @ 2000-05-11 22:43 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Trying to document some of gnus' darkish corners -- please help. 2000-05-11 22:43 Trying to document some of gnus' darkish corners -- please help Rob Browning @ 2000-05-12 15:58 ` Kai Großjohann 2000-05-12 16:28 ` Alan Shutko 2000-05-12 17:09 ` Rob Browning 0 siblings, 2 replies; 4+ messages in thread From: Kai Großjohann @ 2000-05-12 15:58 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Trying to document some of gnus' darkish corners -- please help. 2000-05-12 15:58 ` Kai Großjohann @ 2000-05-12 16:28 ` Alan Shutko 2000-05-12 17:09 ` Rob Browning 1 sibling, 0 replies; 4+ messages in thread From: Alan Shutko @ 2000-05-12 16:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Trying to document some of gnus' darkish corners -- please help. 2000-05-12 15:58 ` Kai Großjohann 2000-05-12 16:28 ` Alan Shutko @ 2000-05-12 17:09 ` Rob Browning 1 sibling, 0 replies; 4+ messages in thread From: Rob Browning @ 2000-05-12 17:09 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-05-12 17:09 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-05-11 22:43 Trying to document some of gnus' darkish corners -- please help Rob Browning 2000-05-12 15:58 ` Kai Großjohann 2000-05-12 16:28 ` Alan Shutko 2000-05-12 17:09 ` Rob Browning
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).