On Tue, 01 Feb 2005, Stephen J. Turnbull whispered secretively:
>>>>> "David" == David Kastrup
David> Because my request that included the specific date and time
David> and comment from the XEmacs developer that could be dug out
David> from the CVS logs
_Your_ CVS logs, and AFAICT Nix is nothing like an XEmacs developer
who happens to use preview-latex. I would absolutely _love_ to be
proven wrong about that, too! "C'mon, Nix, who loves ya, baby!"
I'm afraid I've suffered multiple hardware failures and near-crippling
RSI over the last year plus, which has pretty much killed my ability to
develop *anything* :(
I've got a new keyboard (yay Maltron!) and my RSI is fading accordingly,
and I'm slowly easing myself back into things; I expect that in a month
or so I'll be able to actually *do* something about some of the millions
of bugs I triggered that everyone I know seemingly keeps, er, bugging me
David> It would appear obvious that _if_ somebody was
David> do the necessary research but considered it to take some
David> time, he would indicate this, at the very least to save
David> others doing unnecessary work.
Why, David, I had no intention of doing the necessary work if Nix, or
Uwe, or Steve Youngs, or Richard Stallman would do it for us. Some of
Apologies! My guilt glands are in full flow :(
I'll see what I can do to compensate by describing this bug a little
more clearly. (I've learnt a lot about that sort of stuff since 2002:
I've been doing a lot more reviewing other people's code in my day
job, so I had to get better...)
David> A thorough research on the mailing list also turns up
David> where Nick describes the problem origin after hunting it
Thank you. Now we have a place to start---this is actually about 20%
of the way to a bug report at this point!
Oh dear, I remember this little monster now. Despite my poor wording in
that post it is *not* a dired bug; it's a problem with the interaction
between insert-file-contents-internal and the file-name-handler-alist.
... and no, the underlying bug is *not* fixed, David: sorry. This is my
fault: I reprehensibly vanished off the face of the Earth before fixing
So here's the bug report I was too dilatory to provide (or maybe I did
provide it: I can't remember.)
A:file-based extent read of a PNG file (which is what we were trying to
do) trips png_normalize(), which trips off simple_image_type_normalize(),
which calls make_string_from_file() to read the file data in.
That's how basically all images get read in XEmacs right now, if I follow
the code correctly.
*That* calls Finsert_file_contents_internal like so:
Finsert_file_contents_internal (file, Qnil, Qnil, Qnil, Qnil, Qnil, Qnil);
Because the last two arguments are nil, no charset conversion should
happen, which is obviously the right thing in this case.
Finsert_file_contents_internal says, near the top,
/* If the file name has special constructs in it,
call the corresponding file handler. */
handler = Ffind_file_name_handler (filename, Qinsert_file_contents);
if (!NILP (handler))
val = call6 (handler, Qinsert_file_contents, filename,
visit, start, end, replace);
i.e., if there's a matching handler, it gets called, *and that handler
does not get told what coding systems we're using for this read*.
Now dired has a function `dired-check-file-name-handler-alist',
which inserts, as I said,
'("." . dired-handler-fn)
into the file-name-handler-alist whenever there is a dired buffer open.
That function's sole purpose is to track updates to directories that
dired buffers are open on, so they `magically update'. So it inhibits
itself and thunks down to the underlying call for absolutely every
(apply op args)
So the call chain runs like this:
call applicable coding system for file ops
dired-handler-fn (or any other coding-system-for-read <-----
The problem happens to be tripped internally by the glyph-instantation
code but is *not* specific to it: you can reproduce it by opening a
dired buffer and trying to read something into any buffer at all using
`insert-file-contents-internal' with CODESYS set to anything other than
what `coding-system-for-read' is set to. Watch the CODESYS get ignored.
(I saw this on a non-MULE XEmacs: file-coding being applied at the wrong
time is enough to corrupt PNG files quite badly!)
The only solution I can think of is to locally bind the codesys argument
to `coding-system-for-read' inside Finsert_file_contents_insernal:
would that be acceptable? If it is, I can spin a patch in the next
day or so.
[snip more bickering caused by my dilatoriness, argh! Sorry!]
`Blish is clearly in love with language. Unfortunately,
language dislikes him intensely.' --- Russ Allbery