Re: dired and {coding-systems|MULE} together breaks `make-glyph'.
On Wed, 17 Apr 2002, Michael Sperber mused:
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
Thinko. I meant, of course, Finsert_file_contents_internal :(
I think you're talking about Finsert_file_contents_internal
which
indeed is called from make_string_from_file and does what you
describe.
Quite so. Sorry for the confusion.
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?
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