From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: Sending attachments Date: Mon, 06 Jul 2009 16:47:22 +0900 Message-ID: References: <87k52rzyn1.fsf@benthic.rattlesnake.com> <873a9fw6dt.fsf@catnip.gol.com> <87y6r7yp1y.fsf@stupidchicken.com> <0922916E-B9DD-41C4-8A3D-8550CDD56B62@mit.edu> <83r5ww1m3k.fsf@gnu.org> <871vovsvi8.fsf@catnip.gol.com> <83ljn324xd.fsf@gnu.org> <87skhbrdz3.fsf@catnip.gol.com> <83hbxr0zc6.fsf@gnu.org> <87hbxqrha4.fsf@catnip.gol.com> <83d48e1oz6.fsf@gnu.org> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1246866476 24256 80.91.229.12 (6 Jul 2009 07:47:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jul 2009 07:47:56 +0000 (UTC) Cc: eliz@gnu.org, yandros@MIT.EDU, yamaoka@jpl.org, ding@gnus.org, emacs-devel@gnu.org To: ams@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 06 09:47:49 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MNivU-0001xF-CH for ged-emacs-devel@m.gmane.org; Mon, 06 Jul 2009 09:47:48 +0200 Original-Received: from localhost ([127.0.0.1]:60435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNivT-00048b-L5 for ged-emacs-devel@m.gmane.org; Mon, 06 Jul 2009 03:47:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MNivO-00048H-UH for emacs-devel@gnu.org; Mon, 06 Jul 2009 03:47:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MNivK-00046d-3N for emacs-devel@gnu.org; Mon, 06 Jul 2009 03:47:42 -0400 Original-Received: from [199.232.76.173] (port=33018 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNivJ-00046X-VY for emacs-devel@gnu.org; Mon, 06 Jul 2009 03:47:38 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.193]:49271) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MNiv8-0005ft-8w; Mon, 06 Jul 2009 03:47:27 -0400 Original-Received: from relay11.aps.necel.com ([10.29.19.46]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n667lMAM015296; Mon, 6 Jul 2009 16:47:22 +0900 (JST) Original-Received: from relay31.aps.necel.com ([10.29.19.20] [10.29.19.20]) by relay11.aps.necel.com with ESMTP; Mon, 6 Jul 2009 16:47:22 +0900 Original-Received: from dhlpc061 ([10.114.112.173] [10.114.112.173]) by relay31.aps.necel.com with ESMTP; Mon, 6 Jul 2009 16:47:22 +0900 Original-Received: by dhlpc061 (Postfix, from userid 31295) id 0573752E206; Mon, 6 Jul 2009 16:47:22 +0900 (JST) System-Type: x86_64-unknown-linux-gnu Blat: Foop In-Reply-To: (Alfred M. Szmidt's message of "Mon, 06 Jul 2009 02:37:32 -0400") Original-Lines: 128 X-detected-operating-system: by monty-python.gnu.org: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:112069 gmane.emacs.gnus.general:68650 Archived-At: "Alfred M. Szmidt" writes: > (1) We must still maintain message-mode as well, so mail-mode's > "simplicity" yields no obvious code maintenance Benefit. > > Seeing that we have already rcirc vs. erc, rmail vs. gnus vs. vm > vs. mh (which each has their own mail sending mode!), viper > vs. vi-mode vs. vile; a small _derived_ mode can't be the problem. For all of the above, the duplication _does_ cause additional maintenance burden, and more user confusion. However, for many such packages the UIs of the various alternative modes are quite different, so it's much easier to argue that the alternatives are all "necessary" (in some cases that may not be true -- e.g., I'm not sure if vi-mode is still really necessary), and that the burden is justified. mail-mode vs. message-mode is a particular funny case because the message-mode UI seems to be pretty much a superset of mail-mode's UI (if it isn't, please give details). ERC vs. rcirc is a case where ERC is more functional, but has a very different feel to the user. My vague sense is that maybe people are saying they feel the same is true of mail-mode vs. message-mode, but in my own experience, such a difference was not at all obvious. > You already have people who prefer it, and are more than happy to fix > any bugs it has. So, tell me, in concrete terms, _why_ do they prefer it? Well, OK, you may not want to speak for others, so just tell me why _you_ prefer it? How would you be adversely affected if one day, someone snuck up and replaced mail-mode with message-mode? To help you get started, here are a general categories: (1) UI differences (AFAICT, they're very very similar, but I'm sure there are some differences that annoy people -- though in some cases these are probably bugs...) (2) Customization/hook differences -- maybe mail-mode has some great hooks or settings that message-mode doesn't. (3) Behavioral differences -- does mail-mode work with some systems where message-mode doesn't (as I mentioned earlier, mail-mode fails to send for some reason on one of my machines)? Remember, be concrete, and be detailed -- we've all argued enough that people's basic position is clear enough, and I don't see how it's possible to advance this discussion without some actual details... The reason why I sound a bit incredulous is that I've used both, and other than message-mode's extra functionality -- which seemed pretty much invisible to me unless I needed it -- they seemed more or less identical. [Well there are some things, like the fill prefix when filling a header line is different...] > Maintenance is clearly not the issue here. Both modes seem fairly mature, so it's not the problem it might be, but any bugs need to be checked for in both modes, and any new features may need to be thought about in the context of both. Documentation needs to consider both, and worry about making the difference clear to users. But I agree, it's probably not the main issue (though in the abstract it's Not Good to have duplicate code bases). I think, however, that the user burden of the duplication is very real. People do not know, in general, that to get certain functionality they have to use a different mail-sending mode. > Indeed, it's obviously more of a _burden_ to maintain both > modes than it is to maintain message-mode alone (in the case > that we got rid of mail-mode). This burden goes up, of > course, if mail-mode starts getting more features, like the > suggested attachments. > > For such a feature to be properly implmented they wouldn't be in > mail-mode (or any such mode), but in a seperate mode that handles MIME > attachment exclusivly. If message-mode handles this itself, then it > is a sign that it was not properly thought through. That is not at all clear -- AFAIK, much of the actual MIME stuff is a separate library, but MIME covers a lot of aspects of mail encoding, not just attachments, and all of that it's going to need to be hooked into the top-level mode. In any case, I can't defend the quality of the message-mode code. The general code quality or design of mail-mode may well be higher. However, if mail-mode doesn't have the requisite functionality (which certainly seems to be the case), then we could (a) Keep both, and suffer the problems of having both (maintenance burden and user confusion). (b) Fix any bugs / functional inadequacies in in message-mode, and trash mail-mode. Since message-mode largely seems to be a superset from the user's point of view, this option seems to have a fairly small cost. If message-mode's code is bad, then that's a shame, but having message-mode alone is certainly less of a problem than message-mode plus something else. (c) Add the required functionality to mail-mode, fix any other problems with it, and trash message-mode. As mail-mode is missing a lot of functionality, this would seem to have a far higher cost than option (b), but the end result might be better. If mail-mode has better code than message-mode, then ideally we'd choose (c), but in practice, the implementation cost (and associated extra maintenance burden of new code) may make (b) the better choice. > I use it every day for non-ASCII text, and mail-mode has not had any > problems with that. The most obvious problem with mail-mode's handling of non-ASCII text is that it doesn't seem to encode headers correctly (headers in email are annoying, you need to use a whole separate system for encoding them). [and does mail-mode support any non-8-bit transfer encodings? Does it work if the message encoding isn't utf-8, and the user uses multiple languages?] Thanks, -Miles -- Erudition, n. Dust shaken out of a book into an empty skull.