Re: Bugs in xemacs' rmail, flim, mel, and vm

* Problems with rmail & tm -------------------------- Xemacs rmail comes with mime-handling enabled via tm. This - blows up on babyl messages that *aren't* mime messages - blows up on babyl messages that *are* mime messages, in a different way. So if you run xemacs rmail on an rmail file, you are guaranteed to lose.

Some of tm's mime-handling capability is provided by a file mel.el. It turns out that there are *two such files* in the xemacs system: /usr/lib/xemacs/xemacs-packages/lisp/flim/mel.el /usr/lib/xemacs/xemacs-packages/lisp/tm/mel.el They are not functionally identical. Package-loading finds & loads the first. It blows up. The second works.

flim/mel.el defines MIME-DECODE-REGION as follows (defun mime-decode-region (start end encoding) "Decode region START to END of current buffer using ENCODING. ENCODING must be string." (interactive (list (region-beginning)(region-end) (completing-read "Encoding: " (mime-encoding-alist 'mime-decode-region) nil t "base64"))) (funcall (mel-find-function 'mime-decode-region encoding) start end)) However, when you invoke the whole tm mime-viewing system on a *non-mime* message, the ENCODING parameter is nil. When MIME-DECODE-REGION looks up the handler for the nil encoding, it gets nil back from MEL-FIND-FUNCTION, and the funcall bombs out. There are a couple of ways to fix this: - Add a guard to MIME-DECODE-REGION to skip the funcall if the function is nil, something like this: (defun mime-decode-region (start end encoding) "Decode region START to END of current buffer using ENCODING. ENCODING must be string." (interactive (list (region-beginning)(region-end) (completing-read "Encoding: " (mime-encoding-alist 'mime-decode-region) nil t "base64"))) (let ((handler (mel-find-function 'mime-decode-region encoding))) (if handler (funcall handler start end)))) This is what tm/mel.el does (though it uses a simpler lookup mechanism). - Arrange for MEL-FIND-FUNCTION to return a noop handler when you look up nil. - Arrange for the mime-message parser in tm/tm-parse.el to return a proper encoding value when it is asked to parse a non-mime message, instead of nil. - Arrange for rmail to invoke mime viewing *only* when a msg is a mime msg. The first of these options is the most robust, I would say.

We're not done, though. Suppose we implement fix #1, and leave all else as-is, out-of-the-box (i.e., mime handling enabled for rmail). - If we try to read a babyl file we still blow up, because by the time rmail calls rmail-set-message-counters, via this chain rmail-set-message-counters rmail-maybe-set-message-counters rmail-first-unseen-message rmail the mime hackery has switched the current buffer to the mime-preview buffer, which isn't a babyl-format buffer... so the search for babyl's message-delimiters (newline/control-underbar) bombs out. This is a general problem, as I'll show below. At this point, I lost confidence that the rmail/tm interface could be fixed without serious rethinking. Rmail commands assume the current buffer is a babyl buffer. Unfortunately, tm makes these alternate "preview" buffers... and then imports the keymap of the original mail buffer, which contains these rmail commands that assume we're running in a babyl buffer. Boom. This code has been in xemacs for years. But you can blow it up with really, really simple examples. (See below for a simple demo.) After several days of wandering around this code, I must say that it seems like a huge mess. A particular problem is the level of documentation in the source files. I wanted to send you all working, fixed code, instead of this detailed problem report, but the packages involved are so large, complex, and poorly documented that I ran out of time. Sorry 'bout that. I have to go do some work to keep my day job, now.

Suppose we turn off the mime-viewing default in rmail. Then it seems to work. But we now have no way to view mime messages -- and MIME has been essentially non-optional for a couple of years now. Tons of mime mail out there. If you don't handle mime, you don't really have a workable email solution. To see this lossage in action, download this twelve-line babyl file: http://www.cc.gatech.edu/~shivers/tmp/broken-rmail Then say xemacs -q c-u m-x rmail broken-rmail You will lose with a funcall to nil. Now try with the functioning mel.el file xemacs -q m-x load-file /usr/lib/xemacs/xemacs-packages/lisp/tm/mel.el c-u m-x rmail broken-rmail You will lose with a failed search for "\n^_", as rmail tries to count babyl messages in a mime preview buffer that doesn't contain babyl-format anything. Fixes: One of two things needs to be done - Fix the rmail/tm interaction - Provide rmail mime support from an alternate, non-tm package I have stumbled over an emacs-mime.info node describing an alternate mime-handling system that appears to packaged with gnus. Perhaps rmail could be shifted over to that?

While I'm at it, I note that tm seems to have two manuals, tm-view & tm. They appear to have been written in texinfo, then converted to html. You can find the html manuals on xemacs.org, for example. But... - The html versions have broken navigation links, so you can't actually navigate the manuals (unless you guess the right url's and manually edit them, which can be done). - I can't find info or texinfo versions *anywhere*. What's up w/these mystery manuals?

* Problems with vm ------------------ Okay, let's consider abandoning xemacs's non-functional rmail+tm system and trying to read babyl files with vm.