Weird behaviours of message-insert-mime-part.

[Lloyd Zusman <ljz@asfast.com>]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

I'm using `pgnus-0.56' under XEmacs 20.4.

I have some questions about some weird behaviors of the
`message-insert-mime-part' function (`C-a').

I used this function to insert a few images into an email message
to myself.  When I received the message, XEmacs ignored the first
image and instead, displayed the `

[-- Attachment #2: Type: text/plain, Size: 254 bytes --]

...' tag without the leading
`<' or `#'.  In other words, there was a single line in the buffer
consisting of this against the left margin:

   part type=image/jpeg filename="foobar.jpg" description="Foobar">

When composing the message initially, both `

[-- Attachment #3: Type: text/plain, Size: 230 bytes --]

...' tags showed
up fine, with no leading characters deleted.  It appears that the
corruption of this tag occurred during the MIME encoding of the
images immediately prior to the message being sent out.

Following this corrupted `

[-- Attachment #4: Type: text/plain, Size: 724 bytes --]

...' tag in the received message, the
second image displayed fine.  However, this second image was displayed
inline (i.e., within the article buffer) without any buttons on top of
it, even though it was longer than the article buffer.  This is fine
with me, but the fact that this longer-than-buffer image was
automatically displayed inline seems to be contrary to what we have
been discussing in another current thread.

I'm wondering why there were no buttons displayed in the received
message when I created the message with `C-a'.  Also, I'm wondering
about the automatic inline display, even though the image is
longer-than-buffer.

And, of course, I'm concerned about the `<' and the `#' being removed
from the first `

[-- Attachment #5: Type: text/plain, Size: 63 bytes --]

...' tag that was inserted.

-- 
 Lloyd Zusman
 ljz@asfast.com