From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/28570 Path: main.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= Newsgroups: gmane.emacs.gnus.general Subject: Re: Guessing based on file extension Date: 04 Jan 2000 14:41:02 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035165393 30532 80.91.224.250 (21 Oct 2002 01:56:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:56:33 +0000 (UTC) Return-Path: Original-Received: from spinoza.math.uh.edu (spinoza.math.uh.edu [129.7.128.18]) by mailhost.sclp.com (Postfix) with ESMTP id 535F7D051E for ; Tue, 4 Jan 2000 18:21:33 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by spinoza.math.uh.edu (8.9.1/8.9.1) with ESMTP id RAB13808; Tue, 4 Jan 2000 17:17:51 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 04 Jan 2000 17:17:35 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id RAA01066 for ; Tue, 4 Jan 2000 17:17:24 -0600 (CST) Original-Received: from jupiter.rtsq.qc.ca (rtsq.grics.qc.ca [199.84.132.81]) by mailhost.sclp.com (Postfix) with ESMTP id 37854D051F for ; Tue, 4 Jan 2000 18:15:48 -0500 (EST) Original-Received: from ariel.progiciels-bpi.ca by jupiter.rtsq.qc.ca (8.8.8/8.8.8) with SMTP id SAA20462 for <@jupiter.rtsq.qc.ca:ding@gnus.org>; Tue, 4 Jan 2000 18:16:15 -0500 Original-Received: from iro.umontreal.ca (uucp@localhost) by ariel.progiciels-bpi.ca (950413.SGI.8.6.12/950213.SGI) via UUCP id SAA09258 for ding@gnus.org; Tue, 4 Jan 2000 18:19:48 -0800 Original-Received: from titan.progiciels-bpi.ca.progiciels-bpi.ca (unknown [199.84.132.86]) by icule.progiciels-bpi.ca (Postfix) with ESMTP id C8E0D309B; Tue, 4 Jan 2000 14:41:10 -0500 (EST) Original-To: Forum of ding/Gnus users X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m écrit: > François suggested the following definition of this function [...] > If the type is "application/octet-stream", then we look at the thing > after the dot, and use that as the "real" type. The few replies we saw show that opinions seem to be a bit split, and it might be difficult to reach a real consensus. On the other hand, status quo, just for avoiding the choice, might not be the ideal solution either. > On the one hand, this is user friendly. On the other hand, guessing is > yucky. One could add a used config variable to control whether to do it > or not, but if that defaults to nil, then that won't be very used friendly. One negative side-effect would be that, if Gnus gets too clever at deciding the MIME type despite application/octet-stream, Gnus users might lean more easily towards just letting it default in, or might use Gnus as a proof of concept against more proper usage. But as a receiving user, I would like that Gnus be more helpful at recognising types despite the laziness of the submitter programs, and use proper in-lining whenever possible. Simon Josefsson writes: > [...] viewing the attachment as a application/ms-word file might be the > Wrong Thing under some circumstances and leave the choice to the user. This is probably an orthogonal issue, so we have to be careful here at seeing both aspects well separate, with clear mind. The bad of a thing is not necessarily the bad of the other. If someone wants to prohibit automatic in-lining of application/ms-word MIME entities, say (I do not even know if Gnus currently allows it, but just let's suppose it can, for the argument), then the Gnus behaviour is already fine-tunable. Lars gave us a lot of variables to customise how various MIME types get in-lined, preferred, and displayed. Let's presume Gnus has already been set to user's taste, in this area. What would be interesting, in practice, is letting Gnus derive the MIME type from the file extension, given we have application/octet-stream. The customisation will then apply over that derived MIME type, as usual. It is surely sad that so many messages use that application/octet-stream as a catch-all type. As a user receiving many such messages, I would prefer that Gnus does not make me more sad than the situation is already. It could help better, and the little code I submitted is an attempt in that direction. -- François Pinard http://www.iro.umontreal.ca/~pinard