Re: [Q] (RFC) Framework to change dumped defaults on package presence; default mailer to VM if possible.

Let's take this to xemacs-design. Reply-To and M-F-T set. Aidan> Ar an tríú lá is fiche de mí Márta, scríobh Steve Youngs: Aidan> [That last setq should have been (setq mail-user-agent Aidan> 'sendmail-user-agent) . ] Aidan> So, let’s say they have a new account on a remote machine, Aidan> they fire up XEmacs with an empty ~/.xemacs/init.el, they Aidan> type C-x m, and they have the same behaviour that they had Aidan> in the past, It doesn't work that way in practice. VM is pretty robust because Kyle is so conservative, but large packages do break. Aidan> but with the possibility of attaching files Aidan> and having sane treatment of non-ASCII characters. The VM Aidan> mail composition _is_ the sendmail.el composition function, Aidan> _but with MIME._ Extra features also upset beginning users. Sane treatment of non-ASCII characters is not yet really supported in XEmacs, and specifically not in vanilla VM. Granted, VM is a huge step forward over sendmail-user-agent, and it really _should_ be available and recommended. But we can't force it to be available, and although I think we should default to it when available, the user should have the option to use something else. Aidan> I respectfully disagree. MIME is not a bell or a whistle. That is true, but only so far as "Content-Type: text/plain; charset=something-the-user-can-actually-write-in" is not otherwise supported. Attachments etc _are_ bells and whistles. And since what is needed in _core_ is the ability to send build and bug reports, it is arguable that even MIME charset support is unnecessary. Add Default - Builtin, ASCII-only, no-frills mailer. People sometimes get confused if you leave the default implicit. I also think that instead of the package blurbs, we should use something more descriptive and meaningful to novices: You have the following XEmacs MUAs installed: Default -- Builtin, ASCII-text-only, no-frills mailer. (Suitable for bug reports.) 1 - Gnus -- Advanced MUA with powerful mail and netnews features. 2 - MH-E -- Powerful mail processing system. (Depends on separate, properly configured MH installation.) 3 - VM -- Easy to use, full-featured mailer. (NB, for ease of comparison I'm following Steve's outline here, I really think default should be VM, with the other MUAs ordered Gnus, MH-E, builtin.) Aidan> I respectfully disagree. People have better things to do Aidan> than choose among alternatives they neither know nor care Aidan> about when they’re learning a new working environment. This is the appropriate way to think about it, but I think that Steve is right, because people _do_ care about the MUA. If our default mailer could be Outhouse Excess compatible, that would be one thing. But it can't (and you don't know how that relieves my mind!) Furthermore, we already have the facility (novice.el) built-in, custom already works this way, etc. It's not like new users can avoid such choices until they reach Reviewer status! Like it or not, such choices are part of the XEmacs working environment for the foreseeable future. Aidan> And MH-E shouldn’t be in that list unless the mhparam Aidan> command is available, which it won’t be. Unless the user is already an MH user. Anyway, (shell-command "which mhparam") :-) -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.