On Thu, Oct 01, 2020 at 10:01:21AM +0100, Chris Green wrote: > On Wed, Sep 30, 2020 at 02:56:56PM -0500, Derek Martin wrote: > > On Wed, Sep 30, 2020 at 02:21:22PM +0100, Chris Green wrote: > > > On Tue, Sep 29, 2020 at 09:49:52AM -0500, Derek Martin wrote: > > I can't say why Christian gets dates and proper sorting on > > his mail folder directories and you're not; that would take some > > investigation. I could guess that it might be that maildir-aware MDAs > > update the utimes on the folder directory when it delivers a file... > > and even if it's not that, you could do that in your MDA with > > os.utime(), which should force the issue. > > > Now that's a point, thank you, I see a small revision of my Python > filter coming up! :-)
Great, hope that helps you out. Meanwhile... > > They may be maildirs, but in the file browser they are directories, > > for the purpose of navigating the file system. In that context, the > > fact that they are maildirs is not relevant: In the context of > > browsing files, you want info about the files, which is what Mutt > > gives you. This is somewhat configurable (see the manual about > > folder_format), but it's not going to give you any info about the mail > > that's in those directories... Wrong context. > > > But in the mutt/mail context they're mailboxes, Mutt doesn't have just one context, it has a number of them. That's why you have a file brower, a message index, a compose menu, etc... The jobs of those features are not the same, and the functionality provided by them is dependent on their function and the context in which they are meant to operate. The file selection dialog box in Thunderbird isn't going to give you mail-related information about maildirs it sees; but that is the same function and context of Mutt's file browser. > Surely mutt can take a look into directories and, if they're maildir > mailboxes, act accordingly and present the user with useful > information. Putting programmer hat on again, maybe make this an > option as it might take too long on slow systems. But as Cameron and I have both tried to point out to you repeatedly, even on a fast system, it's too expensive. Cameron showed the performance for just one large maildir, taking > 4s, on a fast system with SSD. If you have a lot of these, it's going to take on the order of MINUTES for mutt to calculate all the folder sizes, before it can show you the file listing... on the fastest systems available at consumer-level prices. On slower systems, you're looking at going to make a sandwich, and eating it, before the directory can be displayed. It DOES NOT MAKE SENSE to put this functionality in. The context of the file browser has nothing to do with mailbox management, and the properties of this style of mail store make it prohibitive, so doing it just for the sake of convenience is nonsensical--which is exactly why Mutt has never had it. I'm repeating myself now, but again, the only reason you get it with mbox is because in that case your folders just happen to be ordinary files--it's very fast to get file sizes directly from the file system, and displaying that info is relevant to the actual purpose of the file browser. It is not its purpose to display mail-related info in any capacity, and the overlap exists purely due to coincidental properties of that specific implementation (that is, all of the one-file-per-mail-folder variants) of the mailbox abstraction. With just about any other implementation, providing that information is prohibitively expensive. I haven't made this point yet since I regard it as almost irrelevant given the above, but I would also argue it's not particularly useful information, except in the context of disk space management--which has nothing to do with Mutt. Context is everything. -- 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 due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
