bug#4448: 23.1; unrmail fails if buffer has mixed line endings (patch)

["David J. Biesack" <David.Biesack@sas.com>]

> Date: Wed, 16 Sep 2009 20:17:38 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > This causes the 
> > 
> >                   (re-search-forward "^[*][*][*] EOOH [*][*][*]\n")
> > 
> > in unrmail to fail.
> 
> Yes, by design (although the traceback is not by design).

I turned on debug-on-error to obtain the traceback
 
> > Here is a patch which makes it work, but I don't think this is the correct
> > change; it seems that the correct change would be to account for coding
> > systems.
> 
> Actually, I think the correct change would be to throw an error with a
> meaningful error message.  Babyl files written by Rmail are supposed
> to have Unix EOLs.

"supposed to", but in my case, this has happened multiple times (I have over 40 rmail files with \n in them) whether because rmail-edit, rmail-output, or the fact that I'm running on Windows and my rmail files are on a unix filesystem, or something else.

If you have to modify the code to detect the situation and generate an more meaningful error message, there should be clear instructions on how to fix it.... which is still not very friendly. In that case, you may as well be more robust to begin with and just make it work, at least for this case. (My opinion; I'm certainly going to leave my patch in my installation.)

> Of course, entering the debugger is not a graceful
> reaction, but I don't think we should support incorrectly formatted
> Babyl files.  That way lies madness.

Well, this again goes back to "how did it get incorrectly formatted?" and if Emacs created the problem, Emacs should correct it. I was happily using Emacs/rmail for years until 23.1 forced me to adopt mbox format.

> Thanks.

thanks

-- 
David J. Biesack, SAS
SAS Campus Dr. Cary, NC 27513
www.sas.com    (919) 531-7771