Binary editing problems persist
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?"