MIME attachments?

MIME attachments?

[Hamish Macdonald]

I find that MIME attachments don't get attached in Pterodactyl gnus
0.88.  The MIME headers seem to get generated properly, but the
content (base64 encoded) doesn't get inserted into the message.

Anyone else seen this?

Hamish.

Re: MIME attachments?

[Norman Walsh]

/ Hamish Macdonald <hamishm@lucent.com> was heard to say:
| I find that MIME attachments don't get attached in Pterodactyl gnus
| 0.88.  The MIME headers seem to get generated properly, but the
| content (base64 encoded) doesn't get inserted into the message.
| 
| Anyone else seen this?

A quick test indicates that they are working for me.

                                        Cheers,
                                          norm
-- 
Norman Walsh <ndw@nwalsh.com>      | If you understand: things are as
http://nwalsh.com/                 | they are. If you do not
                                   | understand: things are as they are.

Re: MIME attachments?

[Hamish Macdonald]

>>>>> On 15 Jun 1999 10:32:14 -0400,
>>>>> In message <6w7lp55yc1.fsf@lucent.com>,
>>>>> I wrote:

Hamish> I find that MIME attachments don't get attached in Pterodactyl
Hamish> gnus 0.88.  The MIME headers seem to get generated properly,
Hamish> but the content (base64 encoded) doesn't get inserted into the
Hamish> message.

Hmmm... application/octet-stream attachments are fine.  GIF and JPEG
are not.

Re: MIME attachments?

[Hamish Macdonald]

>>>>> On 15 Jun 1999 10:53:32 -0400,
>>>>> In message <6wbteh4is3.fsf@lucent.com>,
>>>>> I wrote:

Hamish> Hmmm... application/octet-stream attachments are fine.  GIF
Hamish> and JPEG are not.

I created another message, attaching the same application/octet-stream
I'd attached successfully before.  This time I said it was
image/gif. It was attached fine.  It seems only real image files are
hosed.  I did some tracing, and (insert-file-contents filename) in the 
guts of the mml stuff was returning a length of 0 bytes inserted...

Note: things worked fine with 0.84.

emacs-version: "21.1 \"20 Minutes to Nikko\" XEmacs Lucid (patch 2)"
(emacs-version): "XEmacs 21.1 \"20 Minutes to Nikko\" [Lucid] (sparc-sun-solaris2.7) of Thu May 20 1999 on zulas"

gnus-version: "Pterodactyl Gnus v0.88"

Hamish.

Re: MIME attachments?

[Hamish Macdonald]

>>>>> On 15 Jun 1999 10:58:43 -0400,
>>>>> In message <6w3dzt4ijg.fsf@lucent.com>,
>>>>> I wrote:

Hamish> I created another message, attaching the same
Hamish> application/octet-stream I'd attached successfully before.
Hamish> This time I said it was image/gif. It was attached fine.  It
Hamish> seems only real image files are hosed.  I did some tracing,
Hamish> and (insert-file-contents filename) in the guts of the mml
Hamish> stuff was returning a length of 0 bytes inserted...

Definately some sort of screwy XEmacs thing.  When
insert-file-contents returns, the buffer the file was inserted into is
read-only.  When mm-encode-content-transfer-encoding calls
base64-encode-region, it calls (point-min) and (point-max) to get the
bounds of the temp buffer. These both return 1.  Yet when I switch to
the temp buffer, the GIF is visible as an inline gif.  XEmacs
should just insert the contents, no?

Hamish.

Re: MIME attachments?

[Hamish Macdonald]

>>>>> On 15 Jun 1999 11:34:06 -0400,
>>>>> In message <6wemjd32c1.fsf@lucent.com>,
>>>>> I wrote:

Hamish> Definately some sort of screwy XEmacs thing.  When
Hamish> insert-file-contents returns, the buffer the file was inserted
Hamish> into is read-only.  When mm-encode-content-transfer-encoding
Hamish> calls base64-encode-region, it calls (point-min) and
Hamish> (point-max) to get the bounds of the temp buffer. These both
Hamish> return 1.  Yet when I switch to the temp buffer, the GIF is
Hamish> visible as an inline gif.  XEmacs should just insert the
Hamish> contents, no?

0.84 uses insert-file-contents-literally
0.88 uses insert-file-contents

insert-file-contents-literally does the right thing.

Re: MIME attachments?

[William M. Perry]

Hamish Macdonald <hamishm@lucent.com> writes:

> >>>>> On 15 Jun 1999 11:34:06 -0400,
> >>>>> In message <6wemjd32c1.fsf@lucent.com>,
> >>>>> I wrote:
> 
> Hamish> Definately some sort of screwy XEmacs thing.  When
> Hamish> insert-file-contents returns, the buffer the file was inserted
> Hamish> into is read-only.  When mm-encode-content-transfer-encoding
> Hamish> calls base64-encode-region, it calls (point-min) and
> Hamish> (point-max) to get the bounds of the temp buffer. These both
> Hamish> return 1.  Yet when I switch to the temp buffer, the GIF is
> Hamish> visible as an inline gif.  XEmacs should just insert the
> Hamish> contents, no?
> 
> 0.84 uses insert-file-contents-literally
> 0.88 uses insert-file-contents
> 
> insert-file-contents-literally does the right thing.

this is because of the #!%!@@!#%!@#%@!@ing format-alist crap that
automatically inlines images.  This code is bogus and people have been
begging for it to be removed on the beta list for a while. :)

If you set format-alist to nil you should be ok.

-bp

Re: MIME attachments?

[Alexandre Oliva]

On Jun 15, 1999, wmperry@aventail.com (William M. Perry) wrote:

> this is because of the #!%!@@!#%!@#%@!@ing format-alist
                         ^^^^^^^^^^^^^^^^

Wouldn't it be nice if smiley would replace this with something
funnier? :-)

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: MIME attachments?

[Didier Verna]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> On Jun 15, 1999, wmperry@aventail.com (William M. Perry) wrote:
> 
> > this is because of the #!%!@@!#%!@#%@!@ing format-alist
>                          ^^^^^^^^^^^^^^^^
> 
> Wouldn't it be nice if smiley would replace this with something
> funnier? :-)

        Oh, f*ck. My gnus can't display japanese again :-)

BTW, a smiley (unless representing a face) would be too small a picture for an 
/explicit/ representation of what this word means :-)


-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /     ENST, INFRES C201.1       mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   +33 (1) 45 81 73 46
                       75013 Paris, France      Fax.   +33 (1) 45 81 31 19

Re: MIME attachments?

[Hrvoje Niksic]

wmperry@aventail.com (William M. Perry) writes:

> > insert-file-contents-literally does the right thing.
> 
> this is because of the #!%!@@!#%!@#%@!@ing format-alist crap that
> automatically inlines images.  This code is bogus and people have
> been begging for it to be removed on the beta list for a while. :)

It has been removed, fortunately.

> If you set format-alist to nil you should be ok.

set -> bind

Re: MIME attachments?

[Kyle Jones]

William M. Perry writes:
 > Hamish Macdonald <hamishm@lucent.com> writes:
 > 
 > > >>>>> On 15 Jun 1999 11:34:06 -0400,
 > > >>>>> In message <6wemjd32c1.fsf@lucent.com>,
 > > >>>>> I wrote:
 > > 
 > > Hamish> Definately some sort of screwy XEmacs thing.  When
 > > Hamish> insert-file-contents returns, the buffer the file was inserted
 > > Hamish> into is read-only.  When mm-encode-content-transfer-encoding
 > > Hamish> calls base64-encode-region, it calls (point-min) and
 > > Hamish> (point-max) to get the bounds of the temp buffer. These both
 > > Hamish> return 1.  Yet when I switch to the temp buffer, the GIF is
 > > Hamish> visible as an inline gif.  XEmacs should just insert the
 > > Hamish> contents, no?
 > > 
 > > 0.84 uses insert-file-contents-literally
 > > 0.88 uses insert-file-contents
 > > 
 > > insert-file-contents-literally does the right thing.
 > 
 > this is because of the #!%!@@!#%!@#%@!@ing format-alist crap that
 > automatically inlines images.  This code is bogus and people have been
 > begging for it to be removed on the beta list for a while. :)
 > 
 > If you set format-alist to nil you should be ok.

The #!%!@@!#%!@#%@!@ing format-alist crap has been removed from
21.2.  It's still in 21.1.  It should be removed from there, too.

Re: MIME attachments?

[Hamish Macdonald]

>>>>> On Tue, 15 Jun 1999 09:26:36 -0700 (PDT),
>>>>> In message <14182.32444.569083.121837@crystal.WonderWorks.COM>,
>>>>> Kyle Jones <kyle_jones@wonderworks.com> wrote:

Kyle> The #!%!@@!#%!@#%@!@ing format-alist crap has been removed from
Kyle> 21.2.  It's still in 21.1.  It should be removed from there, too.

Would setting format-alist to nil be the equivalent for 21.1 ??

Thanks,
 Hamish.

Re: MIME attachments?

[Kyle Jones]

Hamish Macdonald writes:
 > >>>>> On Tue, 15 Jun 1999 09:26:36 -0700 (PDT),
 > >>>>> In message <14182.32444.569083.121837@crystal.WonderWorks.COM>,
 > >>>>> Kyle Jones <kyle_jones@wonderworks.com> wrote:
 > 
 > Kyle> The #!%!@@!#%!@#%@!@ing format-alist crap has been removed from
 > Kyle> 21.2.  It's still in 21.1.  It should be removed from there, too.
 > 
 > Would setting format-alist to nil be the equivalent for 21.1 ??

Yes.

Re: MIME attachments?

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

> > 0.84 uses insert-file-contents-literally
> > 0.88 uses insert-file-contents
> > 
> > insert-file-contents-literally does the right thing.
> 
> this is because of the #!%!@@!#%!@#%@!@ing format-alist crap that
> automatically inlines images.  This code is bogus and people have been
> begging for it to be removed on the beta list for a while. :)

Yup.

I've now made mml use a version that allows jka-compr to work, but
ignores all other hooks.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: MIME attachments?

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've now made mml use a version that allows jka-compr to work, but
> ignores all other hooks.

Will it work for crypt++?  Some people are using that rather than
jka-compr to compress/decompress their files.

Re: MIME attachments?

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > I've now made mml use a version that allows jka-compr to work, but
> > ignores all other hooks.
> 
> Will it work for crypt++?  Some people are using that rather than
> jka-compr to compress/decompress their files.

It uses this function to figure out what functions to keep:

(defun mm-auto-mode-alist ()
  "Return an `auto-mode-alist' with only the .gz (etc) thingies."
  (let ((alist auto-mode-alist)
	out)
    (while alist
      (when (listp (cdar alist))
	(push (car alist) out))
      (pop alist))
    (nreverse out)))

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: MIME attachments?

[Jan Vroonhof]

Hamish Macdonald <hamishm@lucent.com> writes:

> 0.84 uses insert-file-contents-literally
> 0.88 uses insert-file-contents
> 
> insert-file-contents-literally does the right thing.

N.B. Regardless of the format-alist stuff, Gnus should still use
insert-file-contents-literally.

Jan

Re: MIME attachments?

[William M. Perry]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> Hamish Macdonald <hamishm@lucent.com> writes:
> 
> > 0.84 uses insert-file-contents-literally
> > 0.88 uses insert-file-contents
> > 
> > insert-file-contents-literally does the right thing.
> 
> N.B. Regardless of the format-alist stuff, Gnus should still use
> insert-file-contents-literally.

You have to use insert-file-contents if you want to be able to attach files 
through efs / ange-ftp / rcp / whatever.

-bp

Re: MIME attachments?

[Jan Vroonhof]

> > N.B. Regardless of the format-alist stuff, Gnus should still use
> > insert-file-contents-literally.
> 
> You have to use insert-file-contents if you want to be able to attach files 
> through efs / ange-ftp / rcp / whatever.

That is a bug in insert-file-contents-literally, it really should be
made a file-handler method. Apperently FSF Emacs 20.4 already contains
a a less than ideal fix for this (by assuming jka-compr is the only
handler that will mess up the contents). XEmacs 21.2.x would already
have contained the same fix had I not objected to the way it is done.

insert-file-contents-literally is intended exactly for the
give-me-the-bytes-of-the-file case, so I propose not to reinvent it
but simply use it and fix the doens't-work-with-efs bug, at least that 
fails less silently.

Lars, change it back, please?

Jan

Re: MIME attachments?

[William M. Perry]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> > > N.B. Regardless of the format-alist stuff, Gnus should still use
> > > insert-file-contents-literally.
> > 
> > You have to use insert-file-contents if you want to be able to attach files 
> > through efs / ange-ftp / rcp / whatever.
> 
> That is a bug in insert-file-contents-literally, it really should be made
> a file-handler method. Apperently FSF Emacs 20.4 already contains a a
> less than ideal fix for this (by assuming jka-compr is the only handler
> that will mess up the contents). XEmacs 21.2.x would already have
> contained the same fix had I not objected to the way it is done.
> 
> insert-file-contents-literally is intended exactly for the
> give-me-the-bytes-of-the-file case, so I propose not to reinvent it but
> simply use it and fix the doens't-work-with-efs bug, at least that fails
> less silently.

I don't think I quite understand how you would make
insert-file-contents-literally work for EFS files and yet not let things
like jka-compr and friends get at it.  A file-name-handler is a
file-name-handler.  Unless you make efs NOT use file-name-handler-alist,
and that would be icky.

-Bill P.

Re: MIME attachments?

[Jan Vroonhof]

> > > You have to use insert-file-contents if you want to be able to attach files 
> > > through efs / ange-ftp / rcp / whatever.
> > 
> > That is a bug in insert-file-contents-literally, it really should be made
> > a file-handler method. Apperently FSF Emacs 20.4 already contains a a
>
> I don't think I quite understand how you would make
> insert-file-contents-literally work for EFS files and yet not let things
> like jka-compr and friends get at it.

Simply let jka-compr and friends not implement it, like this (note the 
absence of any patch to jka-comp.el). Only kai has get to work to do
this for rcp.el:

1999-06-15  Jan Vroonhof  <vroonhof@math.ethz.ch>

	* efs.el (efs-insert-file-contents-general): Generalized i-f-c
	function derived from old i-f-c function.
	(efs-insert-file-contents): Use it.
	(efs-insert-file-contents-literally): Use it.

	* files.el (insert-file-contents-literally): Use binary coding
	system (from Morioka san).
	(insert-file-contents-literally): Make file-name-handler method.

	

Index: lisp/files.el
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs-20/lisp/files.el,v
retrieving revision 1.31
diff -u -u -r1.31 files.el
--- files.el	1999/05/13 12:19:37	1.31
+++ files.el	1999/06/16 02:26:06
@@ -874,23 +874,31 @@
 (defun insert-file-contents-literally (filename &optional visit beg end replace)
   "Like `insert-file-contents', q.v., but only reads in the file.
 A buffer may be modified in several ways after reading into the buffer due
-to advanced Emacs features, such as file-name-handlers, format decoding,
-find-file-hooks, etc.
+to advanced Emacs features, such as format decoding, character code
+conversion,find-file-hooks, automatic uncompression, etc.
+
   This function ensures that none of these modifications will take place."
-  (let ((file-name-handler-alist nil)
-	(format-alist nil)
-	(after-insert-file-functions nil)
-	(find-buffer-file-type-function
-	 (if (fboundp 'find-buffer-file-type)
-	     (symbol-function 'find-buffer-file-type)
-	   nil)))
-    (unwind-protect
-	(progn
-	  (fset 'find-buffer-file-type (lambda (filename) t))
-	  (insert-file-contents filename visit beg end replace))
-      (if find-buffer-file-type-function
-	  (fset 'find-buffer-file-type find-buffer-file-type-function)
-	(fmakunbound 'find-buffer-file-type)))))
+  (let ((wrap-func (find-file-name-handler filename
+					   'insert-file-contents-literally)))
+    (if wrap-func 
+	(funcall wrap-func 'insert-file-contents-literally filename
+		 visit beg end replace)
+      (let ((file-name-handler-alist nil)
+	    (format-alist nil)
+	    (after-insert-file-functions nil)
+	    (coding-system-for-read 'binary)
+	    (coding-system-for-read 'binary)
+	    (find-buffer-file-type-function
+	     (if (fboundp 'find-buffer-file-type)
+		 (symbol-function 'find-buffer-file-type)
+	       nil)))
+	(unwind-protect
+	    (progn
+	      (fset 'find-buffer-file-type (lambda (filename) t))
+	      (insert-file-contents filename visit beg end replace))
+	  (if find-buffer-file-type-function
+	      (fset 'find-buffer-file-type find-buffer-file-type-function)
+	    (fmakunbound 'find-buffer-file-type)))))))
 
 (defun find-file-noselect (filename &optional nowarn rawfile)
   "Read file FILENAME into a buffer and return the buffer.


diff -u /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/efs/efs.el~ /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/efs/efs.el
--- /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/efs/efs.el~	Tue Jun 15 20:45:13 1999
+++ /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/efs/efs.el	Tue Jun 15 20:45:13 1999
@@ -88,6 +88,7 @@
 ;;; get-file-buffer
 ;;; insert-directory
 ;;; insert-file-contents
+;;; insert-file-contents-literally
 ;;; list-directory
 ;;; make-directory-internal
 ;;; rename-file
@@ -7011,10 +7012,21 @@
 	    (efs-set-buffer-mode))
 	(error "efs-write-region called for a local file")))))
 
-(defun efs-insert-file-contents (filename &optional visit &rest args)
+(defun efs-insert-file-contents (filename &rest args)
   ;; Inserts file contents for remote files.
   ;; The additional ARGS covers V19 BEG and END. Should also handle the
   ;; CODING-SYSTEM arg for mule. Hope the two don't trip over each other.
+  (apply 'efs-insert-file-contents-general 'insert-file-contents filename args))
+
+(defun efs-insert-file-contents-literally (filename &rest args)
+  ;; Inserts file contents for remote files.
+  ;; The additional ARGS covers V19 BEG and END. Should also handle the
+  ;; CODING-SYSTEM arg for mule. Hope the two don't trip over each other.
+  (apply 'efs-insert-file-contents-general 'insert-file-contents-literally
+	 filename args))
+
+(defun efs-insert-file-contents-general
+         (handled-func filename &optional visit &rest args)  
   (barf-if-buffer-read-only)
   (unwind-protect
       (let* ((filename (expand-file-name filename))
@@ -7055,7 +7067,7 @@
 		   (format "Retrieving %s" abbr)
 		   (efs-cont (result line cont-lines) (filename visit buffer
 								host-type
-								temp args)
+								temp handled-func args)
 		     (if result
 			 (signal 'ftp-error
 				 (list "Opening input file"
@@ -7073,7 +7085,7 @@
 				   (file-readable-p temp))
 			       
 			       (setq i-f-c-size
-				   (nth 1 (apply 'insert-file-contents
+				     (nth 1 (apply handled-func
 						 temp visit args)))
 			     (signal 'ftp-error
 				     (list
@@ -10449,6 +10461,7 @@
 
 ;; I/O
 (put 'insert-file-contents 'efs 'efs-insert-file-contents)
+(put 'insert-file-contents-literally 'efs 'efs-insert-file-contents-literally)
 (put 'write-region 'efs 'efs-write-region)
 (put 'directory-files 'efs 'efs-directory-files)
 (put 'list-directory 'efs 'efs-list-directory)

Re: MIME attachments?

[Lee Willis]

Hamish Macdonald <hamishm@lucent.com> writes:

> Hamish> I find that MIME attachments don't get attached in Pterodactyl
> Hamish> gnus 0.88.  The MIME headers seem to get generated properly,
> Hamish> but the content (base64 encoded) doesn't get inserted into the
> Hamish> message.
> 
> Hmmm... application/octet-stream attachments are fine.  GIF and JPEG
> are not.

JPEG's at least are fine here ... pgnus 0.88 Emacs 20.3.1

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: Re: MIME attachments?

[XEmacs Patches Moderator Robot]

This message mechanically acknowledges receipt of your message to
xemacs-patches; thank you for your submission.

Your message has been forwarded to the xemacs-patches list and to
the XEmacs patch review board for consideration.

Re: MIME attachments?

[Jan Vroonhof]

xemacs-patches-moderator@wonderworks.com (XEmacs Patches Moderator Robot) writes:

> This message mechanically acknowledges receipt of your message to
> xemacs-patches; thank you for your submission.

Sorry, my fault. I was trying to CC my patch all over the world while
still trying to limit the discussion to this list. I want
"Followup-To:" for mailing lists :-(

Jan