Re: dired and {coding-systems|MULE} together breaks `make-glyph'.
>>>> "nix" == nix
<nix(a)esperi.demon.co.uk> writes:
nix> On 17 Apr 2002, Stephen J. Turnbull spake:
> 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.
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