Bug 163866 - xemacs MH-E: mh-compose-insertion doesn't ask for MIME type
xemacs MH-E: mh-compose-insertion doesn't ask for MIME type
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: file (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-21 13:47 EDT by Horst H. von Brand
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 4.14-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-22 03:56:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Horst H. von Brand 2005-07-21 13:47:51 EDT
Description of problem:
mh-compose-insertion always gives MIME type of audio/x-mod

Version-Release number of selected component (if applicable):
xemacs-21.4.17-4

How reproducible:
Always

Steps to Reproduce:
1. Create a draft message using MH-E
2. C-c C-m C-i, give file name etc
3.
  
Actual results:
Attachment is audio/x-mod

Expected results:
Should ask for MIME type

Additional info:
Comment 1 Ville Skyttä 2005-07-21 14:41:06 EDT
Hm, I'm not a mh-e user, and I could not reproduce this in brief tests, so you  
may need to walk me through here... (oh, and mh-e is in the xemacs-sumo  
package). 
  
Anyway, first, do you have the "file" package installed?  If yes, what does  
"file -i -b FILENAME" where FILENAME is the file you're trying to attach  
output? 
 
If the "file" command is not available, you should be asked for the content 
type, otherwise it should be determined based on file's output. 
 
By the way, there's a new xemacs-sumo heading towards the repository as soon 
as the Extras build system is available again, but according to upstream 
changelogs, mh-e hasn't changed. 
Comment 2 Horst H. von Brand 2005-07-21 16:03:17 EDT
Might it be breakage in nmh? I've got nmh-1.1-8.fc4 and xemacs-sumo-20050505-6 here.

file-4.14-1

$ file 4802.1.txt
4802.1.txt: ISO-8859 text

Gives audio/x-mod

$ file J-Planificacion2005-Vinculacion.doc
J-Planificacion2005-Vinculacion.doc: Microsoft Office Document

Also guesses audio/x-mod

I've also tried with PostScript and PDF files, which file(1) identifies fine.
Comment 3 Ville Skyttä 2005-07-21 16:23:10 EDT
I don't know about nmh either.  
  
But just to verify, could you run the file(1) tests    
using the -i and -b arguments to it, for example "file -i -b   
J-Planificacion2005-Vinculacion.doc" (see comment 1)?  That's how mh-e invokes   
file(1).  
   
BTW, here's how I'm trying to reproduce the problem (and failing), is this the 
correct way? 
   
$ rpm -q nmh xemacs-sumo xemacs file   
nmh-1.1-8.fc4   
xemacs-sumo-20050715-1   
xemacs-21.4.17-4   
file-4.13-4   
$ file -i -b pcsc-wrapper-bt-full.txt   
text/plain; charset=iso-8859-1   
$ xemacs   
M-x mh-letter-mode  
C-c C-m C-i  
[...add description etc, no media type asked...]  
  
The result is this in the MH-Letter buffer:  
<#part type="text/plain" filename="~/pcsc-wrapper-bt-full.txt"  
disposition=attachment description=asd>  
<#/part>  
  
All other file types appear to get the correct MIME types too.  
Comment 4 Ville Skyttä 2005-07-21 16:33:08 EDT
Okay, I upgraded to file-4.14-1 on a FC4 box, and "file -i -b foo" returns 
audio/x-mod for everything.  Reassigning... 
  
Comment 5 Radek Vokal 2005-07-22 03:56:22 EDT
Fixed

Note You need to log in before you can comment on or make changes to this bug.