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

nix> preview-latex has triggered another fun bug. nix> The glyph-reading code (in the person of nix> glyphs.c:make_string_from_file()) takes great care to avoid having nix> file-coding conversions apply to the glyphs it reads, to the extent of nix> locally binding `format-alist' to nil. nix> Unfortunately, dired torpedoes it. While you're displaying a directory nix> with dired, there is in the global value of your file-name-handler-alist nix> the element nix> ("." . dired-handler-fn) nix> (note that the first element is a regexp!) nix> Now make_string_from_file calls Finsert_file_contents_literally(); this nix> proceeds to check for a file-name-handler and trigger it, passing it the nix> insert-file-contents symbol. What code exactly are you talking about? Finsert_file_contents_literally doesn't exist in XEmacs, as far as I can see. Instead, `insert-file-contents-literally' is a Lisp function (in files.el) which does this wrt. file-name handlers: (let ((wrap-func (find-file-name-handler filename 'insert-file-contents-literally))) (if wrap-func (funcall wrap-func 'insert-file-contents-literally filename visit start end replace) This looks rather correct. I think you're talking about Finsert_file_contents_internal which indeed is called from make_string_from_file and does what you describe. nix> That dired function then calls that to do the reading --- which *uses nix> coding systems* and may well proceed to assume that your PNG file is a nix> DOS file, reading it in and fubaring it completely. What exactly do you mean by "uses coding system"? Isn't the coding system determined by dynamically binding the `coding-system-*' variables? (Not that I understand anything about coding systems.) I don't understand where they could be trashed, Dired certainly does nothing to explicitly introduce coding systems. Could you be more specific about that? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla