nnfolder doesn't like mime & no base64 extracting(?)

nnfolder doesn't like mime & no base64 extracting(?)

[George J McNinch]

Hi--

Let me be a bit more precise than I was earlier....  I am using XEmacs
20.4.  pgnus 0.33.  I reported a bit earlier that Mime buttons were
not appearing in my article buffers when they should have been
("perhaps silly question" subject).  I use nnfolder for my mail
backend.

I just copied a piece of mime mail to a file and then opened it via
nndoc.  This seems to work -- my "multipart/mixed" piece of mail
appears in the nndoc summary as:

   [ 783: George J McNinch    ] <* mixed> test
R      [  11: George J McNinch    ] <1 text>
R      [ 536: George J McNinch    ] <2 jpeg> "billevans.jpg"
R      [ 216: George J McNinch    ] <3 text> ".emacs"

That looks right to me, and this _didn't_ work in my nnfolder:
mailbox. It is the same piece of mail. I promise.

So I guess I'm reporting that for some reason nnfolder doesn't like
the new mime-ish things. Unless I've done something flaky (which I'm
skeptical of).

I should also report that in the above mail, the content-type header is:

Content-Type: MULTIPART/MIXED; BOUNDARY="-2125855254-1539181240-906838750=:15717"

and the "section" header for the jpeg is:

---2125855254-1539181240-906838750=:15717
Content-Type: IMAGE/JPEG; name="billevans.jpg"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SGI.3.95.980926143910.15717B@galois.math.nd.edu>
Content-Description: 

In the article buffer for <2 jpeg> I see the following

--Article buffer contents:----------------------------------------------
[image/jpeg (billevans.jpg)]



/9j/4AAQSkZJRgABAQAAAQABAAD//gBnY2xpcDJnaWYgMC43LjEgYnkgWXZl
cyBQaWd1ZXQKCkNSRUFUT1I6IFhWIFZlcnNpb24gMy4xMGEgIFJldjogMTIv
MjkvOTQgIFF1YWxpdHkgPSA5MCwgU21vb3RoaW5nID0gMAr/2wBDAAMCAgMC
AgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQERMU
FRUVDA8XGBYUGBIUFRT/wAALCAEXASQBAREA/8QAHwAAAQUBAQEBAQEAAAAA
AAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIh
MUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3

etc...
------------------------------------------------------------------------

Clicking w/ mouse-2 on the button has no effect. Pressing v whilst in
the button and typing xv at the prompt doesn't work (this spawns xv
with no image). Somehow, I assume the image isn't being
"unbase64ed". I wasn't sure when that was supposed to happen.

Best,
George

Re: nnfolder doesn't like mime & no base64 extracting(?)

[George J McNinch]

Very sorry.  I reinstalled pgnus-0.33 and all seems to be OK.  I get
different behavior of multipart/mixed mails in nndoc and nnfolder,
(i.e. I see in nndoct the parts listed as separated messages, and I
don't in nnfolder. But I do now see the mime buttons).

I patched up to 0.33; maybe I did something wrong in that process?
Who knows. Works now.  

(oh, and the base64 extracting does work as well).

A question: is there a way to re-parse .mailcap without restarting the
emacs?


Best,
--George


-- 
------------------------------------------------------------------------
	       George McNinch [Mailto:McNinch.1@nd.edu]
		      <URL:www.nd.edu/~gmcninch>
------------------------------------------------------------------------
Department of Mathematics	|	Phone: (219) 631-6505
University of Notre Dame	|	Fax:   (219) 631-6579
Notre Dame, Indiana 46556-5683	|	Office 366 CCMB
------------------------------------------------------------------------

inconsistent button behavior (was: Re: nnfolder doesn't like mime & no base64 extracting(?))

[John H Palmieri]

Pterodactyl Gnus v0.33
GNU Emacs 20.3.1 (sparc-sun-solaris2.5.1, X toolkit) of Thu Aug 27 1998 on darwin

George J McNinch <McNinch.1@nd.edu> writes:

  [snip]
> ------------------------------------------------------------------------
> 	       George McNinch [Mailto:McNinch.1@nd.edu]
> 		      <URL:www.nd.edu/~gmcninch>
> ------------------------------------------------------------------------

Both of these lines produce buttons when I read the message with gnus,
but the second one doesn't quite work right.  (I don't know if it's
because of the missing 'http://', but the behavior looks buggy to me
regardless.)

As it stands, if I have Netscape (since browse-url-netscape-function
is set to 'browse-url-netscape) running already, then clicking on this
button takes me to

     http://www.nd.edu/~gmcninch

If I don't have Netscape running, then clicking on the button starts
Netscape, but tries to go to the URL

     file:/afs/nd.edu/user4/jpalmier/www.nd.edu/~gmcninch

I understand that the URL may be malformed, but should there really be
a difference in behavior depending on whether I have a web browser
running or not?

(I can't tell how much this depends on the web browser.  With w3,
i.e., with 

   (setq browse-url-browser-function 'browse-url-w3)

the button does the same thing--goes to http://...--whether w3 was
"running already" or not.  I don't feel like installing any Microsoft
products today to test what happens there; and Mosaic goes to the
correct URL if it is *not* running already, but goes to the wrong
place--appends www.nd.edu/~gmcninch to the currently displayed URL--if
it *is* running.)

It certainly could be that gnus (and widget and whatever else) is
doing as good a job as it can on a malformed URL, and then that
different web browsers handle the results differently.  But it could
also be a bug.  Which is it?

-- 
John H. Palmieri
e-mail: palmieri@member.ams.org        205 Computing/Mathematics Building
URL: http://www.nd.edu/~jpalmier/      University of Notre Dame
(219) 631-8846                         Notre Dame, IN 46556

Re: inconsistent button behavior (was: Re: nnfolder doesn't like mime & no base64 extracting(?))

[Alan Shutko]

>>>>> "J" == John H Palmieri <John.H.Palmieri.2@nd.edu> writes:

J> I understand that the URL may be malformed, but should there really
J> be a difference in behavior depending on whether I have a web
J> browser running or not?

It's the way netscape works.  Gnus just passes the URL (which isn't)
to Netscape.  If netscape gets something that looks like a pathname on
the CLI, it uses it as a pathname.  But if you tell it with the
netscape-remote stuff, it assumes it's a HTTP url.

I guess a case could be made that Gnus should do some sanity checks on
URLs before sending them out, but if someone marks something as a URL
and it isn't, it's really their fault, not Gnus.  I'd suggest in cases
like this, simply email off explaining that http:// is only 7
characters and will improve interoperability with all software, and
then cut and paste the partial URL into netscape.

It's not that much work the few times it happens, and by emailing the
person, you'll cause it to happen less.  I don't think anyone _wants_
to cause problems by omitting http:// from URLs, they just don't
realize it makes things more difficult.

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
IBM: It may be slow, but it's hard to use.