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

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.

Attachment: signature.asc
Description: PGP signature

Reply via email to