"Ludwig, Mark" <ludwig.mark@siemens.com> writes:

> I frequently encounter data files that are supposed to be 100%
> ASCII but contain long sequences of NUL characters (ASCII zero).
> (The reasons are out of my control.)
>
> When I first started using EMACS [sic] in 1980, I was delighted
> to find it served as a very fine binary file editor.  It seems
> that modern Emacs no longer is a fine binary file – at least not
> by default.
>
> What happens is that as I scroll through the file, when the NULs
> are visible, Emacs gets into some intensive processing for a long
> time (minutes, sometimes!).  It eventually unwinds and repaints
> the display, but any movement of point sends it into this loop
> again.  I have found that M-< or M-> will quickly reposition away
> from the problem (assuming the beginning and/or end of the file
> do not contain NULs).  Most other movement operations send it
> into the loop.
>
> I understand about encodings, and have messed around with forcing
> it into us-ascii, but it appears not to be related to this CPU
> consumption problem.  Does anyone know how to solve this?  I’ll
> file a bug report if this is a legitimate bug.  I’m just
> concerned that it’s a “feature” of some sort, though I hope not.
>
> Thanks!
> Mark

What about trying `hexl-mode'?

-- 
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591