<<< Date Index >>>     <<< Thread Index >>>

Re: trash folder patch?



On Fri, Aug 27, 2010 at 01:59:58PM -0500, Will Fiveash wrote:
> > Adding a feature does not automatically translate to increased
> > complexity.
[...]
>
> My take is that if the desired function can be achieved via existing
> mutt functionality then why add duplicate code.  

I already gave the answer: more seamless integration and improved
usability.  In general, adding features via macros sucks, because
invariably you want the feature to behave in a way that the macro just
can't quite manage, precisely because full support for the feature you
want to add does not exist.  Macros are mostly great for what they were
primarily intended for: time savings for frequently repeated actions.
I've only tried to solve problems with macros a few times, because
each and every time I've tried, I found the solution lacking.
Invariably I find I'd prefer to do it manually, or just live without
it entirely.  It's not polished, and it's not robust.  Just as in this
case (see Omen's post as to why).

> As to usability, example trash macros could be in the example muttrc
> and documented in the mutt manual.

They could, but that rarely happens AFAIK.  So unless someone like you
wants to contribute a laundry list of useful macros, I think you still
don't have much of a compelling argument against adding this feature,
or any.  And even if you did so, that doesn't solve the problem above.
Always, from the point of view of usability, code is better than a
macro.

> At some point additional code starts to work against one of mutt's
> strong points, that being a fast, light weight mail app.

Yeah, if you're still using it on a PDP-11.  At some point, it does,
sure...  but as time goes by, that point gets farther and farther away
from Mutt's reality.  Mutt's memory footprint is maybe a couple times
what it was when I started using it more than a decade ago (probably
due to the libraries it links against -- not Mutt itself), but the
speed and available RAM on the machines on which I run it has
increased by orders of magnitude (and my hardware is considerably
behind the times).  My currently running Mutt has a footprint of 5MB:

$ ps uax | egrep 'PID|[m]utt'
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
ddm      14171  0.0  1.0   5004  3864 pts/0    S+   Aug17   0:14 
/usr/local/bin/mutt
ddm      27867  0.0  0.1   2140   696 pts/2    S+   09:42   0:00 egrep 
PID|[m]utt

It was probably about 2MB 10 years ago.  By contrast, my desktop 10
years ago had 128MB, whereas today's desktop has 2000MB (and my next,
to be purchased soon-ish, will probably have more like 16,000MB).  The
only truly limiting resource for Mutt's performance is disk I/O, and
as perceived by the user, adding a feature like this one won't change
that aspect of Mutt's performance one iota.  IMO, this argument has
always been a fairly useless one, and proves increasingly so as technology
continues to change.

If you have a specific technological or performance-related argument
to make against adding this feature, I would agree that would be worth
considering.  What you've offered here is just dogma without thought:
the antithesis of technology.  None for me, thanks. =8^)

-- 
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: pgp8BmaQxJ0ep.pgp
Description: PGP signature