I'm still playing around with my nhexl-mode attempt and I'm encournering
some serious performance problems.  One of them seems to be linked to
the fact that the redisplay code somehow seems to treat nhexl-mode's
buffers as one single long-line.

This is probably because all the \n have a display property on them that
makes them appear as an "␊" char.  The buffer's display does have
line separators in the overlays's before-strings, but apparently the
redisplay doesn't pay enough attention to them to notice that they can
be used to stop the search for the beginning of a line.

One related problem (which can be witnessed firsthand from Elisp) is
that all the text between point-min and the window's point is jit-locked
(even though only the text visible in the window should need to be
jit-locked).

Try the code below in the following way:

  % emacs -Q -l .../nhexl-mode.el <someasciifile> -f nhexl-mode
  M-x trace-function-background RET jit-lock-function RET
  M-: (display-buffer "*trace-output*") RET
  C-v C-v C-v C-v C-v
  M-: (put-text-property (point-min) (point-max) 'fontified nil)
  <move mouse to the other frame>

You should now see that jit-lock-function was called for positions 1,
508, 1032, and a few more, even though these are all before window-start.

This makes nhexl-mode completely unusable except on small buffers
(whereas some of the motivation for nhexl-mode was to have an
hex-editor that works even for very large files).


        Stefan