On Sun, Sep 04, 2005 at 08:25:20PM -0700, Brendan Cully wrote: > > This is probably the easiest to code... but the down side is it > > introduces yet another folder-format-specific inconsistency in mutt's > > UI, which is something that I personally don't like. I strongly > > believe that the data format should have no impact on the behavior of > > the UI, ever. > > I would like to agree, but in practice some formats make some > operations much cheaper or more expensive than others. This argument has always struck a sour note with me... and especially these days where hardware has gotten so fast. Often new features or suggestions to improve consistency have been shot down in the name of computing expense, but to a large extent I think this argument has become a red herring, if it wasn't always... For example, downloading every message body in a large IMAP folder in order to do a full-text regular expression search is expensive and slow... but people still do it; if the user wants to do it, they should be able to. Likewise, as substring searches will be faster for ALL formats, I think it would be nice to have that feature too, especially since it is the most common kind of search people want to do, and because it makes searching IMAP folders MUCH faster. I'd even go so far as to say this should be considered the default mode for searching, on account of the gains in performance it would offer. But, as another person pointed out in this thread, sometimes regex searching is required to get what you want, and since it's already implemented anyway, that should remain available to Mutt's users, for all formats. That's why I'm in favor of the extra commands... > To really preserve consistency we'd just keep the status quo - super > slow client-side full text searches. When performance gets bad > enough I think it's probably worth sacrificing some consistency. I really can't agree. Computing is one of the few places where you can have your cake, and eat it too. That is, you can implement both, and let the users choose which one they prefer to use... By arguing against features on the basis of performance, especially when those features are format-specific, you're basically telling the user that you know best, and they should not want to perform that operation, because you say so. You're basically making decisions for users that they should not be willing to wait for some features to execute with certain mail folder formats, because it would take too long, IN YOUR OPINION. But I think that people who use Mutt are smart enough to understand the performance implications of the formats they have chosen to use with Mutt; if they're willing to wait, why shouldn't they have the option? Computing expense is, IMO, never a good reason to avoid consistency of UI for different data formats. After all, if a particular operation is done frequently enough that the user decides waiting for it is too slow with their chosen format, they can always convert to a different one, if it is important enough... The other major reason not to code consistent UI functionality is code complexity. This is where improved modularity would really make a big difference, I think. The whole idea behind modular code is to break tasks down into small, manageable operations, and provide a consistent API to those operations. Thus it becomes much easier to code and test these more difficult cases, and much easier to know that you've got it right. That's the whole case for modularity, and I think all of Mutt would benefit greatly from it. But, even lacking that, I don't think arguing against good functionality and consistent UI design on the basis of code complexity has ever been a very compelling argument either... If the users want the functionality, and someone is willing to write and test the code (or even has done so already), then why should users not benefit from it? The only remaining reason is code bloat, which also has become a lame excuse, IMO... Computers now come with 100x more *RAM* than the amount of disk space available on the first computer I used to read e-mail... We've improved the speed and storage capacity of computers specifically so that we COULD add all those whiz-bang features that people want in their e-mail client (and other programs). As it stands, Mutt uses far less computing resources than a lot of the more popular e-mail clients, so I don't see how code bloat or computing expense make valid arguemnts against implementing much of anything, anymore -- not when the most popular[*] e-mail client in existence is roughly 100x the size of Mutt. Even the editor many people use to compose their mail with Mutt, the Emacsen -- probably the most popular editor amongst Linux users, at least -- has a VSZ[1] of somewhere on the order of 5x Mutt! More importantly, if your code is designed well enough, people who really really need the leanest e-mail client possible (because they are still living in the dark ages, computationally speaking) could always just exclude the whiz-bang features with ./configure --disable blah. Mutt is already designed that way... Just make sure the really expensive stuff gets its own configure options. On modern computing hardware, these issues (computing expense and code bloat) really have become non-arguemnts. [*] If you prefer to think that most people use Outlook out of necessity, or even ignorance, as I do, then feel free to substitute "most commonly used" for "popular" in the text above... ;-) [1] VSZ = the total amount of virtual memory (RAM + swap) used by a process. -- 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:
pgpMtlxniuwhA.pgp
Description: PGP signature