From xemacs-m  Fri Dec 13 00:23:59 1996
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with SMTP id AAA05564 for <xemacs-beta@xemacs.org>; Fri, 13 Dec 1996 00:23:58 -0600 (CST)
Received: (qmail 15839 invoked by uid 52477); 13 Dec 1996 06:24:02 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@xemacs.org>
Subject: Re: 20.0b30: file-name-handlers incongruity
References: <y9l682akdlp.fsf@modas.informatik.uni-tuebingen.de>
From: Sudish Joseph <sudish@mindspring.com>
Date: 13 Dec 1996 01:24:02 -0500
In-Reply-To: sperber@informatik.uni-tuebingen.de's message of 10 Dec 1996 09:28:18 +0100
Message-ID: <yviag21b2c8t.fsf@atreides.mindspring.com>
Lines: 22
X-Mailer: Red Gnus v0.74/XEmacs 20.0

Michael Sperber [Mr. Preprocessor] writes:
> load-internal and insert-file-contents-internal call
> file-name-handlers for load and insert-file-contents respectively, but
> with argument lists that are too long.  (This breaks EFS.)

> I'm not sure the attached patch is politically correct; another
> possibility would be to call the handlers directly from load and
> insert-file-contents.

What's the final word on this?  Is this patch going in to the next
20.x beta or is this going to be handled some other way?  I'm applying
it...when efs breaks it leaves all file handling in a really bad
state, unfun.

Thanks a bunch for the patch, I incorrectly reported this at the time
of beta30 as a problem with mule-files.el.  

The symptoms are fun--you don't get a backtrace buffer coz view-less
can't load once you try an "f" in a dired buffer.  If view-less is
necessary for getting a backtrace easily, shouldn't it be dumped?

-Sudish

