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