Re: safe_call1 considered harmful

[Kenichi Handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> The change below was presumably made to avoid errors in functions that
> are put on the various *-coding-system-alist variables.  Those errors
> might have been caused by the recent changes in several modes that now
> use a cons cell `(FILENAME . BUFFER)' instead of just the file name as
> the argument to find-operation-coding-system (when the operation is
> insert-file-contents), because some packages put functions on the
> file-coding-system-alist that are not ready for the cons cell.

> I think the change in coding.c is for the worse: it masks such
> problems from us, so instead of seeing bug reports, we sweep the
> problems under the carpet, where they run risk to be left undetected
> until after the release.

> A case in point is the function find-buffer-file-type-coding-system
> that dos-w32.el adds to file-coding-system-alist: it was not modified
> to support the change in the find-operation-coding-system's interface,
> and caused files with DOS EOLs uncompressed from archives to be shown
> with the ^M characters.  This happened because
> find-buffer-file-type-coding-system throws an error, but safe_call1
> silently ignores it.

> So how about if we undo the change below?

Ah, hmmm, I didn't think about such a situation.  The change
was to avoid the backward incompatiblity reported by the
attached mail.

But, by considering this problem again, I found another
solution than calling find-operation-coding-system with
(FILENAME . BUFFER).  That is to provide an extra argument
BUFFER.  Then, we can keep backward compatibility and
find-buffer-file-type-coding-system works as before, and, by
modifying po-find-file-coding-system to check that extra
argument instead of checking if FILENAME is cons or not, we
can make it work well too.

Do I still miss something?  If not, I'll try to change the
current code along that line.

---
Kenichi Handa
address@hidden

Date: Sun, 28 May 2006 10:23:16 +0200
From: Sven Joachim <address@hidden>
MIME-Version: 1.0
To: Kenichi Handa <address@hidden>
In-Reply-To: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Cc: address@hidden
Subject: Re: Coding system of compressed PO files is not recognized
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham     
version=3.0.3

Kenichi Handa wrote:
> Do you mean that, po-compat.el was able to detect a coding
> system of compressed PO file correctly before my change?

No, it wasn't.  But at least it was able to visit the file
without getting an error. ;-)



_______________________________________________
emacs-pretest-bug mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug