On Wed, Nov 02, 2005 at 02:23:18PM +0000, Chris Green wrote: > The one thing I will miss when I go from mbox to maildir (which I'm > planning to do for ease of backing up) is an indication of folder size. I heartily agree; in fact I occasionally make the point on mutt-dev that -- from the user's perspective -- mbox and maildir should function identically (albeit with somewhat different performance of various operations, which is unavoidable). The information displayed to the user should be identical regardless of format, and the difference in feature set should be nil. The user should not need to consider the storage format to get the desired feature set (excepting cases where the format makes something technically impossible, which is rare), nor should the user need to know or care about the storage format at all, until and unless performance becomes an issue for them. Usually when I bring up this idea, it's in response to a specific feature inquiry/request from someone else, like yours. Usually when I advocate such a thing, one or more people on the dev list complain, "That would be too slow." Often that is somewhat true, though with improvements in the design of the code, in many cases that performance hit could be minimized... But just as often, I think it's just nonsense, as other mailers have those features without being absurdly slow. Even when it does impact performance, I still think the feature set should be the same. Others argue that there should be a difference, because having different formats means that you should be able to optimize differently. I think reasoning is sound, but the conclusion is nonsense. That is, yes: you should be able to optimize for different formats. But that doesn't mean the feature set should be different; it means the user should choose the format which gives them the best performance for the operations they do most often. I (and others) have been reluctant to code patches for Mutt to provide such features, because historically when someone on the dev list makes such a complaint about performance, it means any such patch doesn't stand a snowball's chance in hell of making it into the mainstream code. I (and those same others) think that maintaining patches for features that (obviously, IMO) just plain should be present in the code is not a very good use of time. That said, the developers have been a lot better about accepting new features and patches lately, so this may be a good time to bring it up again. > With mbox when one looks at real mbox folders (as opposed to > subdirectories) one sees the folder size displayed (if there's a %s in > $folder_format). With maildir the folders are *always* subdirectories > so one just gets a boring 4096 (or maybe some other power of 2) for > the size, not very useful. Right. > It should be possible I would have thought to display the count of > messages in the folder, are there any plans to do this, or is it > perchance available as a patch? The latter question is one that you should ask on mutt-dev rather than this list. I believe the answer to the former is "no." I've CC'd the dev list, but you'll need to subscribe, or review the list archives, to see what others have to say about it. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpaEJbHORTrj.pgp
Description: PGP signature