Having earlier experienced under-the-bonnet changes of 0x0D to 0x0A when using hexl-mode to edit a file, whose coding had been set to binary, I have just re-compiled from the latest CVS sources, and the problem persists. Did I mention that I compile --with-mule? In the past I have looked at the documentation and code involved in file coding in a Mule environment, and given myself a fright. I have also looked on in bemusement at some of the exchanges in this list about file coding. Does anyone have any suggestions as to how this problem can be resolved? Can it be solved? Is there an assumption that one of the EOL transformation must always be applied? The info has this: Each of the coding systems that appear in this list--except for `binary', which means no conversion of any kind--specifies how and whether to convert printing characters, but leaves the choice of end-of-line conversion to be decided based on the contents of each file. and... In contrast, the coding system `binary' specifies no character code conversion at all--none for non-Latin-1 byte values and none for end of line. This is useful for reading or writing binary files, tar files, and other files that must be examined verbatim. The easiest way to edit a file with no conversion of any kind is with the `M-x find-file-literally' command. This uses `binary', and also suppresses other XEmacs features that might convert the file contents before you see them. *Note Visiting::. Note the reference to `find-file-literally'. grepping my source files yields only one reference, in files.el, as follows: (if rawfile ;; #### FSF 20.3 sets buffer-file-coding-system to ;; `no-conversion' here. Should we copy? It also ;; makes `find-file-literally' a local variable ;; and sets it to t. nil (after-find-file error (not nowarn)) (setq buf (current-buffer)))) Setting `binary' by hand, as noted, does not prevent bitrot. Has no one else seen this problem? What is the avenue of attack? Is this the sort of change that is guaranteed to break something else? Yours faithfully, Peter -- __ /__ Peter B. West pbwest(a)netscape.net / http://www.powerup.com.au/~pbwest / "Lord, to whom shall we go?"