chandran@rd.nttdata.jp (04/08/91)
The FAQ includes the following: > !8. What options should I use? > > BERK: Do NOT include the BERK option! BERK breaks the mh-format > functions that take apart address lines, for example mbox, from, and > friendly. This would really put a crimp on my replcomps file. > On my man pages for scan, it says that On hosts where MH was configured with the BERK option, scan has two other switches: `-reverse', and `-noreverse'. These make scan list the messages in reverse order. In addition, Now I don't know about you, but I like to see the most recent messages first, especially when I have 500 plus messages in my inbox folder. It seems that "scan -reverse" is the only way to get this effect. The man pages implies that I must use the BERK option, whereas the FAQ suggests (insists?) otherwise. Where do I go? Or did this feature/bug go away in 6.7.1? I use version: MH 6.6 #5[UCI] (lotus) of Mon Oct 1 18:08:20 JST 1990 options: [BSD42] [SUNOS4] [BERK] [TTYD] [DUMB] [MHE] [NETWORK] [BIND] [RPATHS] [ATZ] [MHRC] [SBACKUP='"#"'] [SENDMTS] [SMTP] The man page also go on to make the intriguing remark: scan will update the MH context prior to starting the list- ing, so interrupting a long scan listing preserves the new context. MH purists hate both of these ideas. Why do purists hate the second idea (or the first)? Sharat
jerry@ORA.ORA.COM (Jerry Peek) (04/08/91)
In <9104080926.AA13072@lotus.rd.nttdata.jp>, chandran@rd.nttdata.jp wrote: > On my man pages for scan, it says that > On hosts where MH was configured with the BERK option, scan > has two other switches: `-reverse', and `-noreverse'. These > make scan list the messages in reverse order. In addition... > man pages implies that I must use the BERK option... > I use > version: MH 6.6 #5[UCI] (lotus) of Mon Oct 1 18:08:20 JST 1990 Under MH 6.7, you don't need BERK to use scan -reverse. > The man page also go on to make the intriguing remark: > scan will update the MH context prior to starting the list- > ing, so interrupting a long scan listing preserves the new > context. MH purists hate both of these ideas. > Why do purists hate the second idea (or the first)? I wouldn't call myself a purist :-) and I didn't write the code or the man page. But the idea here, I think, is that an interrupt means "stop now!". A purist might think that the context should only be updated when an operation finishes successfully and would expect that an interrupt would keep the context from being updated too. But an average user will see that there's output from the folder's scan listing and assume that the context has already changed to that new folder. So, making scan work this way keeps non-purists happier. I guess. Here's an example that shows a context change not being made because an operation (removing a message) fails. This bites a lot of non-purists: % folder -fast foo % rmm +bar rmm: no cur message % folder -fast foo You might think that the "rmm" would change the current folder to "bar" -- but it doesn't, as you can tell from the second "folder -fast". About "scan -reverse": I don't know what anyone has against it. At the risk of offending all the purists out there :-), I think it's great. --Jerry Peek, jerry@ora.com, uunet!ora!jerry
jromine@yoyodyne.ics.uci.edu (John Romine) (04/10/91)
> On hosts where MH was configured with the BERK option, scan > has two other switches: `-reverse', and `-noreverse'. These > make scan list the messages in reverse order. > ... MH purists hate both of these ideas. The short answer is that all MH commands process messages in numerical order. Having scan work in reverse make it inconsistent with the standard user interface. Personally, I prefer to use "scan last:20". I think "scan -reverse" is now standard without the BERK option. -- John Romine