On Wed, 17 Apr 2002, Michael Sperber mused: Thinko. I meant, of course, Finsert_file_contents_internal :( Quite so. Sorry for the confusion. The problem is this. You have a buffer-file-coding-system-for-read; let's say it's the default, 'undecided. Now obviously this should only be used when reading in things that might plausibly be textual, right? So, not PNG glyphs, nor any other kind of glyph which calls make_string_from_file() in its instantiation routine. (make_string_from_file locally binds format-alist to nil and calls down to Finsert_file_contents_internal() with a nil coding system (`no-conversion').) Alas, if the filename of the glyph being instantiated matches a handler in the file-name-handler-alist, that handler gets invoked to do the work, but the operation passed to the handler is 'insert-file-contents, not 'insert-file-contents-literally --- so when the handler goes off and reinvokes the operation on the remote site, it uses the wrong function call, and takes coding-systems into account even though glyph-loading explicitly tried to turn them off. (Note that if Finsert_file_contents_internal is called from, say, insert-file-contents --- the common case --- you'll *want* to pass in 'insert-file-contents as the handler operation! I wonder if the handlers are being invoked in the wrong routine?) dired is tied in because it sets up a handler for *everything* whenever there is a dired buffer open, so every glyph read until you close the buffer goes through the file-name-handler-alist, and glyphs may undergo erroneous `conversion' and get completely fubared. Sorry for the unclarity; I fear this isn't much better, but this is a really rather knotty problem :) -- `Unless they've moved it since I last checked, travelling between England and America does not involve crossing the equator.' --- pir

ms> Dired sure isn't doing it. It may be an accessory before the fact though. I ran into a problem in latin-unity.el, which hangs a function on write-region-pre-hook, where the hook gets called once, then dired's (yep) handler gets called from write-region-internal, which calls the hook again. And (like here) for some reason the standard "i'm-already-in-a-handler" flag didn't do the right thing. Now, this hook I'm talking about is right smack in the middle of the coding system detection stuff. I don't _know_, but there's a certain odor wafting from that general direction.... So if you can say "I want binary and THAT IS THAT" you should bind `coding-system-for-read' to binary. If you're already doing that, I'm not sure what's happening. There is also i-f-c-pre-hook which you should be able to use to kneecap autodetection according to a computation in almost all cases. (The only thing that it can't override is if coding-system-for-read is bound.) That's what it's for. HTH, if not I'll try to take a look at the code in question tomorrow. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

nix> (This all applies with any other explicit coding-system too; nix> if you pass *any* coding system to nix> Finsert_file_contents_internal() and don't bind the nix> coding-system-for-read to the same value, you're asking for nix> problems. I have a feeling that perhaps nix> Finsert_file_contents_internal should do the binding itself.) No. coding-system-for-read is a badly designed escape for user code. The functions that implement io should not touch it. nix> The Lisp `insert-file-contents-literally' binds the nix> file-name-handler-alist to nil explicitly, so ISTM that nix> someone's seen this before but didn't think of all the C-side nix> code that could be doing things wrong, too :( What it means is that for backward compatibility reasons, we believed ourselves forced to replicate all the broken Mule interfaces. We really should get rid of many of them. nix> How can I? This is glyph-instantiation code: I have no nix> (direct) control over when it's called! You can bind variables in C, of course. nix> --- well, in practice nix> I know it'll always be called when I call `make-glyph', but I nix> feel it's decidedly unwise to rely upon that. Welcome to Mule. nix> (Of course, I've replaced that code with code that sets the nix> :data and does an explicit `insert-file-contents-literally', nix> and *that* works.) OK. Well, for future reference you could also put (lambda () 'binary) on i-f-c-pre-hook. (nil doesn't work because it means the function failed, and you'll fall through to the autodetect code.) You'd be hosed if somebody bound c-s-f-r before instantiating a glyph, but you can argue that anybody who does that deserves to lose. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

nix> On 17 Apr 2002, Stephen J. Turnbull spake: nix> The reason is this. I'll delineate the control flow in the case that's nix> breaking me more carefully. nix> make_string_from_file() or something else calls nix> Finsert_file_contents_internal(), passing a nil `codesys'. (Note, nix> however, that all the coding-system variables may have different values, nix> and have not been rebound.) nix> This then finds an active handler matching this file and calls it, nix> passing it Qinsert_file_contents. nix> That handler then eventually does the work by funcalling that operation nix> --- which, because the coding-system variables haven't been rebound, nix> proceeds to insert the file with a coding-system other than nil. Ah, I see. Now could we simply bind `coding-system-for-read' and `coding-system-for-write' to the `codesys' parameter of Finsert_file_contents_internal when calling the file-name handler and expect The Right Thing to happen? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla