Re: Need some bug/version info

On Tue, 01 Feb 2005, Stephen J. Turnbull whispered secretively: 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 about. 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...) 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 it. 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); goto handled; } 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 operation: (apply op args) So the call chain runs like this: call applicable coding system for file ops png_normalize coding-system-for-read simple_image_type_normalize coding-system-for-read make_string_from_file coding-system-for-read Finsert_file_contents_internal nil dired-handler-fn (or any other coding-system-for-read <----- handler fn) Finsert_file_contents coding-system-for-read Finsert_file_contents_insernal 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