Re: newline cache

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 23 Apr 2014 20:33:10 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>     I suggest to try it; you might be surprised.  I tried it on a 7MB mbox
>     file, and didn't see any significant slowdown.  The reason is simple:
>     the mbox buffer is almost always narrowed, and find_newline, which is
>     the workhorse of the function I wrote, and also the main suspect, only
>     looks within the restriction.
> 
> Well, I could arrange to narrow to the current message
> before running the test.  Maybe that will do enough.

Some additional info about this.

I didn't install newline-cache-check in a post-command-hook, primarily
because I was unsure which buffer to check the cache in.  Instead, I
waited for some problem to happen first.  This came in the form of a
qp-encoded mail that Rmail didn't succeed in decoding for display,
complaining thusly:

  Warning: corrupt attribute header in message

I then invoked newline-cache-check in INBOX, which came up OK.  Next,
I invoked newline-cache-check in " *message-viewer INBOX*", and bingo:
it detected a corruption.  The viewer buffer is narrowed to a single
email message, as it should be.  The cache thinks that there are only
2 newlines in the narrowed region, while the truth is there are much
more, and what the cache thinks is actually a tiny subset of the
truth:

(newline-cache-check (get-buffer " *message-viewer INBOX*"))
 => [[27793944 27797783] [27788878 27788912 27788938 27788985 27789043 27789110 27789123 27789161 27789182 27789233 27789306 27789344 27789365 27789416 27789488 27789503 27789575 27789645 27789660 27789731 27789771 27789809 27789830 27789881 27789986 27790091 27790187 27790220 27790282 27790355 27790836 27790897 27790959 27791021 27791083 27791145 27791207 27791269 27791331 27791393 27791455 27791486 27791590 27792014 27792056 27792563 27792636 27792680 27792719 27792762 27792840 27792873 27792947 27792965 27793010 27793054 27793112 27793144 27793173 27793174 27793251 27793328 27793405 27793482 27793559 27793636 27793713 27793790 27793867 27793944 27794020 27794097 27794174 27794251 27794328 27794405 27794482 27794559 27794635 27794712 27794789 27794866 27794943 27795020 27795097 27795174 
 27795251 27795328 27795405 27795482 27795559 27795636 27795713 27795788 27795863 27795939 27796015 27796091 27796166 27796243 27796320 27796397 27796474 27796551 27796628 27796705 27796782 27796859 

So now I will install a check in post-command-hook and try to see what
causes the corruption.

(As you see, my Rmail buffer is very large, about 29MB, but I don't
think it matters, because the check is always done in a region
narrowed to a single email message, and how large can that be?)