=- Patrick Schoenfeld wrote on Wed 17.Oct'07 at 9:50:41 +0200 -=
> > color header ^dispo... color1 color2
>
> that is what I currently do, but you cannot call this a
> notification. In fact it is nothing more then a mark. And so its a
> workaround again.
Hum... now we are at preference level and therefore how we name
things. Functionally it's the same: you are being informed to look
at it.
It's just the degree/ method required/ given which is perceived
differently. For me it would be enough (if I actually needed/ wanted
such support), for you it isn't. So you'd have to put a little more
effort into it, but nothing that would be needed for everyone to
this degree. And once you have a working solution, it can be
published for easy use by everyone else, the form doesn't matter
anymore, everyone can copy+paste. If it's "popular" enough it could
be distributed in /contrib.
> > One action: macro(s).
>
> Well, you are right that this enables me to write a return receipt
> by just one keypress (although it requires me to write a script
> that actually does a MUAs job),
Where is the MUA's job defined?
You have a complete list with "must have" and "must not have"?
Where do you draw the line of what a MUA is/ does?
For example, is ~/.mailcap usage "external" by your definition?
You'd prefer a mutt-proprietary solution?
> but again it is just a workaround because what you (and others,
> and me if it is abused by people) find annoying is what this
> feature lives from.
I don't know what you mean, but I'm only annoyed that people ask for
a special unique template answer to be hardcoded while it can be
(easily for my taste) achieved as it is.
I see justified uses for the feature generally, just no requirement
for it being hardcoded.
Such discussion has risen before and will rerise until there is a
policy/ guideline declared to give us a clue what dis-/qualifies for
mutt, i.e. what's the target audience and goal of mutt.
> It is like the question: "Should all messages flagged as deleted
> beeing purged?". For a big number of users its neccessary to ask
> this or similar questions, because otherwise it won't work.
I don't deny you the option to use it or not, since you can have it.
You just don't like what you can have, or the work that you'd have
to put on top of it to make it perfect (for your taste).
> > Simple to me.
>
> Well, its not that hard to achieve it, but it isn't simple either.
> One needs to write a script, test it, configure a macro -- the
> last one is by far the simplest part. Its possible, but error
> prone, again.
The same applies to a hardcoded variant, or do you write perfect
C-code from scratch?
> > As usual, we never know the exact numbers and therefore who's
> > right.
>
> Ehh. You miss that I ask about a very common and wide spread
> feature, not about something all to specific.
"common" based on what?
I don't know that many conciously working with it (and being happy
about it ;).
> Again: I'm not asking for a feature that cooks my morning coffee,
> but other then that I ask for a feature which is wide spread and
> often used in business.
No, not yours alone, but together with all the other ones it slowly
will be able to, and put some sugar in your cup, too. Care to lift a
finger at all anymore? ;)
If that's the killer argument, then use Outlook: it's the closest to
the quasi-standard of the business world.
Why should mutt run after business standards, when business is so
stupid to measure only in numbers (of lame OL{users}) rather than
quality (of mutt{ers})?
> You should have seen in this thread, that I am not the only one
> that thinks that this is a common feature.
So is news-reading, eMail-filtering, spam-control, mime-support and
what not... all of that could be _much_ better when integrated into
mutt.
Oh, why not use TB or OL instead, it does all of that and
return-receipts, too?!
Hmm, why do people try to convert mutt into yet another clone of
existing MUAs rather than using them right on?
I know, it's not your single feature alone that turns mutt into TB
or OL clone, but all those inclusion requests together do.
> > No message-hooks needed.
>
> Well, but they are the only possibility to make it nagging enough. ;)
D'oh, ... if you really need that.
One "golden rule" is to adjust the environment to the users'
convenience.
Another is that the very same rule means stagnation: you miss the
chance to improve your processing (or confirm it's the best, by
trying alternatives).
The first way to do things is not always the best (ever ;).
> > It's just one of many other "mutt must have".
>
> I don't know whats those 'many other', but mutt does support
> nearly all common email features I am aware off.
See above, and many other more or less known/ popular/ supported
niche features/ patches/ improvements.
Which should go in and which not? Why this and not the others?
Numbers don't work as argument, since we never know the _real_
numbers to use them in favour of or against any features.
And numbers alone should never be a justification, the mass isn't
always right.
> It even supports Delivery Status Notifications that are (as far as
> I can see that) less wideley supported and therefore even more
> useless.
Uh, you can run after every quasi-standards defined by mass of users
or lead the crowd by what is not only convenient for the short-sight
but also sensible in the long run.
All of that, of course, based on the still unknown goals of mutt.
Besides, DSN comes before MDN: you can't respond to which hasn't
arrived on the server.
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
