Re: dired and {coding-systems|MULE} together breaks `make-glyph'.

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.