Re: Binary editing problems persist
"Peter B. West" <pbwest(a)netscape.net> writes:
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?
This is of course an inexcusable bug. Can you give a recipe to
reproduce? Note that you must specify the coding system before reading
in the 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?
hexl seems broken for Mule at the moment. hexl-find-file now does some weird
conditioning on the system type. Maybe a sync with the hexl from FSF
Emacs 20.4 is in order.
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::.
This function does not exist, maybe it should be reinstated.
The closest function that does is insert-file-contents-literally.
That function is currently also broken (I have a patch but am waiting
for a new version of EFS)
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?
A start would be to sync hexl-mode from FSF emacs. Since they have
mule always, they must have fixed the coding problems.
If it uses i-f-c-literally, just give me yell and I will get it fixed.
Your problems are exactly why Mule has a bad name. It breaks stuff
that used to work, the API changes all the time and thus function are
broken and the documentation is out of date.
Jan