Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!sun-barr!newstop!exodus!argv From: argv@turnpike.Eng.Sun.COM (Dan Heller) Newsgroups: comp.mail.mush Subject: Re: Priorities in 7.2.0 Message-ID: <3672@exodus.Eng.Sun.COM> Date: 29 Nov 90 06:30:09 GMT References: <1990Nov27.215502.25496@ee.rochester.edu> Sender: news@exodus.Eng.Sun.COM Organization: O'Reilly && Associates Lines: 44 In article Mark Sirota writes: > I have a couple of suggestions regarding the priority-setting mechanism > introduced in 7.2.0. It's too bad we didn't get a large sample of beta testers for this. Your input would have been valuable :-). On the other hand, I still can't find a "different" way to do things despite your suggestions... see below. > However, there are two problems with this. First, messages without a > priority wind up last, rather than first, as they probably should. So I This is basically where I disagree.. I think higher priority messages should be listed first. Given that you want it the other way around, I see your problem and your idea about reversing the priorities and the sort seems to be the only way around it (and is also a reasonable idea). > My other problem is that the sort -S appears to just sort alphabetically by > the Status: header or something. This is not right; whether or not the > article has been replied to should not matter. The sorting order for status is, unread, preserved, replied, saved, printed, forwarded, old (and read) and lastly, deleted messages. It's debateable whether or not this is the best thing, but it's too arbitrary to say what's best.. It's also been that way forever ...sigh I sometimes sort mesages by status so I can find those that I haven't replied to yet :-). Of course, the option to do subsorting is really where this comes in most handy. That is, sort by author and then by status so I can group all the messages from someone together and group those that I haven't replied to separately. > One last suggestion - is running all these separate pick commands slow? It > seems it. It would be nice if I could combine a search on both the To: and > Cc: headers in one pick command. I have always thought that "pick -t" should combine To and Cc info together, but I just never thought to do it at the right time. The pick commands generally aren't slow because the routines that get the information from the headers are pretty fast. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.