From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Sending attachments Date: Fri, 10 Jul 2009 18:02:28 +0900 Message-ID: <87skh4lxln.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87k52rzyn1.fsf@benthic.rattlesnake.com> <873a9fw6dt.fsf@catnip.gol.com> <87y6r7yp1y.fsf@stupidchicken.com> <87ljn1dcc4.fsf@stupidchicken.com> <4A5485D0.5060808@gnu.org> <87d48b9trl.fsf@catnip.gol.com> <871vor45w8.fsf@iki.fi> <87y6qz8d1y.fsf@catnip.gol.com> <87eispzixw.fsf@marauder.physik.uni-ulm.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1247216859 23371 80.91.229.12 (10 Jul 2009 09:07:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jul 2009 09:07:39 +0000 (UTC) Cc: Reiner Steib , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 10 11:07:32 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 1MPC1W-0001NQ-Vx for ged-emacs-devel@m.gmane.org; Fri, 10 Jul 2009 11:04:07 +0200 Original-Received: from localhost ([127.0.0.1]:53615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPC1W-000681-FH for ged-emacs-devel@m.gmane.org; Fri, 10 Jul 2009 05:04:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPC1P-00062m-CC for emacs-devel@gnu.org; Fri, 10 Jul 2009 05:03:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPC1K-0005qd-2c for emacs-devel@gnu.org; Fri, 10 Jul 2009 05:03:58 -0400 Original-Received: from [199.232.76.173] (port=47769 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPC1J-0005qH-UC for emacs-devel@gnu.org; Fri, 10 Jul 2009 05:03:53 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:42406) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MPC1G-0002zs-Mp; Fri, 10 Jul 2009 05:03:51 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id B6A951537B8; Fri, 10 Jul 2009 18:03:48 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1AF2A1A3002; Fri, 10 Jul 2009 18:02:29 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 5bbff3553494 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:112286 Archived-At: Richard Stallman writes: > Neither does Gnus (and probably MH-E, too). Viewing inline > vs. attachment can be toggled interactively or specified through > `mm-inline-override-types'. > > In theory, that kind of recommendation might be useful. > But in practice, since the readers decide heuristically True, but shouldn't we focus on users of smarter readers, and on our own use cases? Most Emacs users don't use such dumb readers. They use Gnus or another advanced implementation which will normally respect the recommendation. > whether to display inline, users mostly have no reason > to go out of their way to offer a recommendation. > It is better normally not to ask. That may be true in many users' practice. However, I find myself offering a recommendation about 10-20% of the time, because I disagree with the default. For example, some projects include images. I generally do not want a new version of an image displayed in the buffer, I want it saved to the project tree. But when I'm sending mail to a local users' group of the last meeting with pix of somebody's system, I often do want it inlined. I've been asked how I do that by non-Emacs users on several occasions, so I know that there are readers out there that do respect this header. Patches are another example. Sometimes patches are intended to be reviewed, but discouraging cut and paste from mail buffers (of non-Emacs MUAs) is a good idea since they often munge the text of both patches and Sure, the user can (if they're lucky or wilful enough to be using a good MUA like Gnus) toggle the display or save an inlined attachment to a file if they want. But it takes me ~0.2 seconds (1 keystroke) to accept the default 80% of the time when it really doesn't matter, ~1 second (1 keystroke) to accept the default when it matters, and ~2 seconds (2 keystrokes with completion) to change it. I think that's a small cost to advertise this feature, and give the expert user the option by default. I realize that there are users with disabilities etc such that the cost is much higher. However, I suggest they may be better served by a feature that evaluates the quality of the default offered, and short circuits the question when the program is "pretty sure" the default is correct. Eg, I don't think anybody really would want tar.gz displayed inline by default. Ditto large PDFs. It would also be possible to specify a customizable alist of MIME types with values 'attachment or 'inline, allowing the user to specify ones that should automatically be given a particular disposition. Something like that must already be part of MML, although if it's customizable I didn't find it. This may be way more complex than you would like, of course. Thing is, that complexity is going to pop up at every turn as you develop these features.