On Thu, Oct 31, 2019 at 10:20:21AM +0000, John Long wrote: > On Wed, 30 Oct 2019 15:49:05 -0500 > Derek Martin <inva...@pizzashack.org> wrote: > > > On Wed, Oct 30, 2019 at 11:31:21AM +0000, John Long wrote: > > > That doesn't really help. From my point the issue is not only what I > > > have to configure or what can be configured, but also how much code > > > is behind doing that. Less code is easier to manage than more code. > > > I can't see the benefit of junking up mutt with HTML or anything > > > else that is out of scope for a command-line mail client. Remember, > > > some of us use mutt on a console with no GUI.... > > > > Who is harmed more? Users who have the feature but don't want it, or > > users who need the feature but can't get it? > > That doesn't fall into the category of harmed. I'm not sure of the > timing but I believe in most cases people chose to use mutt after HTML > email was already in common (ab)use.
Mutt's been around since 1995. Many of us have been using it since the beginning, or soon after. HTML mail was not nearly so prevalent then as it is now. > And I would venture to say that virtually all of the people who use > mutt either as their only email client or along with others, chose mutt > because of its simplicity. I'll have to beg to differ. In my experience most people use Mutt because of its power. Mutt is just not simple... all that power comes at a cost. > It seems to be contrary to the direction and purpose of mutt to make > it do everything anybody wants. And if you search the archives for my posts, you will very frequently see me making that same argument. But not when it comes to functionality that is an essential part of handling e-mail, which, like it or not, this now is for many/most people. Mutt's lack of ability to handle HTML e-mail *well*, *natively*, gets in my way just about every single day. If that's not true for you, great! That in no way means it isn't true for lots of people. > The harm of making the app more complicated and adding a lot of code is > real, For sure. > and it directly affects the user of mutt whether he's new or old. This is false. The issue is not how it affects the user--Mutt's longstanding practice is to make such features able to be entirely configured out of the program, which means they impact the user exactly zero, once configure is run (if you want that, that is--you do need to compile it yourself if you're that anal about what features are compiled in since the distros generally (correctly) expect that users want all the features available). Then, even if you don't compile it out, it still doesn't impact the user at all if they don't *use* it. This sort of feature is not one that complicates code paths that you always hit; it's one that sits entirely separate and lies dormant if you don't use the feature. The real issue is that more code makes the code base more complex and harder to maintain. There's always a tradeoff between that and in providing features. When the feature is a fundamental aspect of doing what your application does, then the chioce should be to add the functionality. You can argue handling HTML mail is not a core function of handling e-mail all you like, but if you do you're just wrong. -- 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
