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

Re: mutt/2169: Four suggested changes



The following reply was made to PR mutt/2169; it has been noted by GNATS.

From: Alain Bench <veronatif@xxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc: "Scott B. Marovich" <marovich@xxxxxxxxxx>
Subject: Re: mutt/2169: Four suggested changes
Date: Mon, 25 Sep 2006 12:54:59 +0200 (CEST)

 Hi Paul! And hi Scott.
 
  On Thursday, September 21, 2006 at 23:55:39 +0200, Paul Walker wrote:
 
 > the headline was way too long.
 
     Reduced at last! Thanks! :-)
 
     1 report, 1 bug or wish, 1 title, 1 patch. No more confusing megamix
 overlong things, please. For common sense, contact your local dealer.
 
 
 > I'd agree with tamo - breaking this into four separate change reqs
 
     Me too. But I'd question the need for 4 points. I mean that:
 
  -2) copiousoutput: That's a misunderstanding of Mutt's design, and the
 proposed change would break the autoview and attachment menu dual
 command ability. That's a no-go.
 
  -3) $implicit_autoview quadoption: This doesn't make sense to me.
 Repeatedly prompting user for display of each part, when mails can have
 various number of parts... This seems to contradict one Mutt design
 principle: Have user interactions as predictable as possible.
 
     One could argue that it's an option, off by default, and that some
 people may like it in some circumstances. On one side I could agree. But
 I doubt many people may like this prompting behaviour. If its only OP
 and 2-3 other people, that's bloat, and is a no-go.
 
     But definitely: As coded, crude yes/no prompts without any
 indication of which part, type, size, or filename it commands, this is
 only pure annoyance: Rejected.
 
 
     This keeps 2 points open:
 
  -1) Local address mangling: Problem not understood, needs more infos.
 Proposed patch seems broken, giving bad results: Vanishing addresses.
 
  -4) Mono example in RTFF1: Valid wish. Good manuals want examples.
 Unfortunately the point is not covered by the patch.
 
 
     Scott: Please describe the address mangling problem.
 
     May I also suggest that discussing ideas with Mutt users or
 developpers before making any coding may help to cleanly design things?
 You see, you made the effort to make a patch sustaining your
 suggestions, which is very welcome, and we thank you very much for this.
 But now the 3 points covered by your patch are all broken or rejected.
 What a waste of energy!
 
 
 Bye!   Alain.
 -- 
 Followups to bug reports are public, and should go to bug-any@xxxxxxxxxxxxx,
 and the reporter (unless he is a member of mutt-dev). Do not CC mutt-dev 
mailing
 list, the BTS does it already. Do not send to mutt-dev only, your writings 
would
 not be tracked. Do not remove the "mutt/nnnn:" tag from subject.