bug#22097: Ispell: lazy highlighting doesn't work properly.

[Alan Mackenzie]

Hello, Eli.

On Sat, Dec 05, 2015 at 03:23:42PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 5 Dec 2015 11:42:30 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > emacs -Q
> > C-x C-f src/xdisp.c
> > Adjust frame/window configuration such that the buffer is displayed in a
> >   window at least 50 lines high.
> > M-x ispell

> > Press the spacebar several times until "xdisp" on line 34 is highlighted.
> > Notice that the next occurrence of "xdisp" (L48, in the diagram) hasn't
> > been lazily highlighted.  This is a bug.

> > Press the spacebar several times more until "xdisp" on L48 is
> > highlighted.  The occurrence on L34 is now lazily highlighted as it
> > should be.

> This is a "feature".  Ispell skips regions determined by certain
> regexps, see ispell-skip-region-alist.  In this case, the ASCII-art
> diagram around the second occurrence of "xdisp" includes regions that
> match some of the regexps (AFAICT, the '+' character followed and
> preceded by '-' triggers that).  Lazy highlight doesn't want to try
> matching in those skip-regions, and since it cannot support
> non-contiguous regions, it simply limits itself to the beginning of
> the first such region, which happens to be before the second "xdisp".

Ah.  I didn't know this.

> IOW, the lazy highlight, as coded, should not be expected to highlight
> all the matching misspellings in such situations.

However, the bug manifests itself a bit later on in plain text.

There's a paragraph starting at L199 about bidi.  After several more
hits on the space bar, the first occurrence of "bidi" (L201) gets
highlighted; the second occurrence (on the same line) gets lazily
highlighted.  The third (L204) and fourth (L205) remain unhighlighted.

Hit the spacebar another time.  All four occurrences are now
highlighted.

As far as I can see, there's nothing remotely ASCII-arty in that
paragraph.  Unless the "---" sequences are somehow being interpreted as
ASCII-art.

I'll look into this.

> If we think this is a grave limitation (do we?), then we need to
> invoke isearch-lazy-highlight-new-loop more than once, until we get to
> the end of the window.  I don't know enough about
> isearch-lazy-highlight-new-loop to tell if this will work, but
> hopefully someone else here will.

This would require quite a bit of modification to
isearch-lazy-highlight-new-loop, and possibly its callers, which I would
guess to be more work than it's worth, at the moment.

-- 
Alan Mackenzie (Nuremberg, Germany).