6:33 p.m.
"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
1:23 a.m.
New subject: Binary editing problems persist
Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote:
"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.
The bug is caused by file-coding, the design of which is, well,
"very sub-optimal".
Try this patch (which I made long ago when I went mad while
venturing into the dark recesses of file-coding). I'm not sure it's
complete, though (you may need some C source code changes).
[ P.S. -- crypt.el is also broken. We talked about this a while back,
but I never got around to submitting any patches. ]
--
Darryl Okahata
darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
===============================================================================
*** /tmp/hexl.el Tue Jan 13 22:38:01 1998
--- hexl.el Wed Sep 1 16:47:12 1999
***************
*** 241,246
(dehexlify-buffer)
;; Prevent infinite recursion.
(let ((hexl-in-save-buffer t)
(buffer-file-type t)) ; for ms-dos
(save-buffer))
(setq modified (buffer-modified-p))
--- 241,250 -----
(dehexlify-buffer)
;; Prevent infinite recursion.
(let ((hexl-in-save-buffer t)
+ (buffer-file-coding-system 'binary)
+ (coding-system-for-write 'binary)
+ (jka-compr-compression-info-list nil)
+ (jam-zcat-filename-list nil)
(buffer-file-type t)) ; for ms-dos
(save-buffer))
(setq modified (buffer-modified-p))
***************
*** 260,266
(interactive "fFilename: ")
(if (or (eq system-type 'ms-dos) (eq system-type 'windows-nt))
(find-file-binary filename)
! (find-file filename))
(if (not (eq major-mode 'hexl-mode))
(hexl-mode)))
--- 264,273 -----
(interactive "fFilename: ")
(if (or (eq system-type 'ms-dos) (eq system-type 'windows-nt))
(find-file-binary filename)
! (switch-to-buffer
! (find-file-noselect filename nil t))
! )
! ; (find-file filename))
(if (not (eq major-mode 'hexl-mode))
(hexl-mode)))
***************
*** 568,573
(setq buffer-undo-list nil)
(let ((binary-process-output nil) ; for Ms-Dos
(binary-process-input t)
(buffer-undo-list t))
(shell-command-on-region (point-min) (point-max) hexlify-command t)))
--- 575,582 -----
(setq buffer-undo-list nil)
(let ((binary-process-output nil) ; for Ms-Dos
(binary-process-input t)
+ (coding-system-for-read nil)
+ (coding-system-for-write 'binary)
(buffer-undo-list t))
(shell-command-on-region (point-min) (point-max) hexlify-command t)))
***************
*** 581,586
(setq buffer-undo-list nil)
(let ((binary-process-output t) ; for Ms-Dos
(binary-process-input nil)
(buffer-undo-list t))
(shell-command-on-region (point-min) (point-max) dehexlify-command t)))
--- 590,597 -----
(setq buffer-undo-list nil)
(let ((binary-process-output t) ; for Ms-Dos
(binary-process-input nil)
+ (coding-system-for-read 'binary)
+ (coding-system-for-write nil)
(buffer-undo-list t))
(shell-command-on-region (point-min) (point-max) dehexlify-command t)))
3:52 a.m.
New subject: Binary editing problems persist
I'd like someone on xemacs-beta to test this patch.
Darryl, could you put your stamp of approval on this patch, i.e. if
you feel it's the Right Patch, then send it to
xemacs-patches(a)xemacs.org, and we'll try to apply it to the sources.
Martin
9126
days inactive
9127
days old
2 comments
3 participants
participants (3)
-
Darryl Okahata -
Jan Vroonhof -
Martin Buchholz