From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/23828 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: MIME variables Date: 05 Jul 1999 06:16:48 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: <87so74o1dp.fsf@pc-hrvoje.srce.hr> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035161491 4127 80.91.224.250 (21 Oct 2002 00:51:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:51:31 +0000 (UTC) Return-Path: Original-Received: from farabi.math.uh.edu (farabi.math.uh.edu [129.7.128.57]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id AAA03101 for ; Mon, 5 Jul 1999 00:21:48 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by farabi.math.uh.edu (8.9.1/8.9.1) with ESMTP id XAB00566; Sun, 4 Jul 1999 23:13:53 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 04 Jul 1999 23:14:27 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id XAA29464 for ; Sun, 4 Jul 1999 23:13:47 -0500 (CDT) Original-Received: from quimbies.gnus.org (bang.netfonds.no [195.1.89.231]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id AAA02829 for ; Mon, 5 Jul 1999 00:12:38 -0400 (EDT) Original-Received: (from larsi@localhost) by quimbies.gnus.org (8.8.7/8.8.7) id GAA06429; Mon, 5 Jul 1999 06:24:07 +0200 Mail-Copies-To: never X-Now-Reading: Bryan Cholfin (ed.)'s _The Best of Crank!_ X-Now-Playing: Eurythmics's _1984 (For the Love of Big Brother)_ Original-To: ding@gnus.org In-Reply-To: Hrvoje Niksic's message of "04 Jul 1999 15:55:46 +0000" User-Agent: Gnus/5.070092 (Pterodactyl Gnus v0.92) XEmacs/21.2 (Sumida) X-Face: &w!^oO~dS|}-P0~ge{$c!h\ writes: > I think the third element should be a function that will be called > with one argument, the MIME part. Besides being more Lispy, it allows > the programmer to inspect the part when making the decision. Yes, but it's more convenient the current way. The default value is ("image/gif" mm-inline-image (mm-valid-and-fit-image-p 'gif handle)) ("image/tiff" mm-inline-image (mm-valid-and-fit-image-p 'tiff handle)) [...] ("text/html" mm-inline-text (locate-library "w3")) Of course, I could just wrap all these in `lambda's, which would make things more better, although more verbose. As well as making the magic `handle' dynamic variable explicit. I dunno. > Also, the variable could probably stand a better name. > `mm-inline-media-tests' is, uhm, less than suggestive. Well, they are tests to see whether media can be displayed inline... :-) > > `mm-inlines-types' > > This, on the other hand, says what types are to be displayed > > inline, if they satisfy the conditions set by the variable above. > > It's a list of MIME media types. > > Maybe this should also allow a function, or a list of them. The idea is that the first variable says whether something is possible, and if so, how to do it, while the second says whether we want it or not, so I don't see any need to re-specify a function here. The first variable will probably not be altered by the user, while the second probably will be. > > `mm-automatic-display' > > This is a list of types that are to be displayed "automatically", > > but only if the above variable allows it. That is, only inlinable > > parts are usually displayed automatically, but in the end, this is > > up to the display agent that's using the MIME library. > > Another one that could be named better. I, for one, am not sure what > "automatical" display means, and how it differs from "inline". In a Gnus context, this specifies which types that are displayed when you select an article. This is usually a subset of the types that can we want to be inlined. For instance, we can inline audio/*, but we don't want it to be displayed automatically. > > `mm-attachment-override-types' > > Some MIME agents create parts that have a content-disposition of > > `attachment'. This variable allows overriding that disposition and > > displaying the part inline. > > I think this variable is misconceived, at least as far as text/plain > goes. Many patches are rightfully sent out as "attachments", and I > don't get the button for them (I have to press `K b' explicitly, which > is quite slow.) But patches shouldn't be text/plain, since they aren't... > Mind you, it's perfectly fine for the type to be *displayed* by > default, but the button should still be there for attachments. Broken > software that generates bogus content-dispositions should not be > catered to. I agree with that. Perhaps I should just alter the default to exclude text/plain, and then the user who want to cater to such software can add it? > > `mm-all-images-fit' > > If non-`nil', all images will be deemed to fit into the buffer, > > even when they don't. > > This requires further explanation and possibly a rename. How about: I've included your version. > Consequently, a good name could be something like > `mm-display-large-images-externally' or > `mm-display-externally-images-larger-than-window', or... `mm-inline-large-images'. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen