bug#33446: 26; `isearch-lazy-highlight-update' in MASTER today

[Drew Adams <drew.adams@oracle.com>]

I ran into this bug today using my setup, which reflects the code for
`isearch-lazy-highlight-update' that was added recently to isearch.el.

Dunno why or how, but for some reason I got in a situation where
`isearch-lazy-highlight-window' is live and is not the selected window.
In fact it is in a different frame.  And there is no lazy-highlighting
showing there and no search in progress there.  I'm willing to guess
that this is not a normal situation that I got myself into. ;-)  But
I think there is nevertheless a bug somewhere in the Isearch code.

The `isearch-lazy-highlight-update' code does this:

(save-selected-window
  (if (and (window-live-p isearch-lazy-highlight-window)
           (not (memq (selected-window)
                isearch-lazy-highlight-window-group)))
      (select-window isearch-lazy-highlight-window))

That causes the window in the other frame to be selected.
It's not there that I wanted to do
`isearch-lazy-highlight-update'.  If there is no lazy
highlighting to be updated in the selected window then
I'd expect that `isearch-lazy-highlight-update' would in
that case be a no-op.  Why do we move to another window
to do it, even if for some reason `isearch-lazy-highlight-window'
is non-nil?  (I don't know why it is non-nil in my case.)

The code then does this:

  (setq window-start (window-group-start))
  (setq window-end (window-group-end))

This causes `window-end' to be nil.  Should `window-group-*' here
be passed window `isearch-lazy-highlight-window'?

In any case, then the code does this:

  (save-excursion
    (save-match-data
      (goto-char (if isearch-lazy-highlight-forward
                     isearch-lazy-highlight-end
                   isearch-lazy-highlight-start))
      (while looping
        (let* ((bound (if isearch-lazy-highlight-forward
                          (min (or isearch-lazy-highlight-end-limit
                                   (point-max))
                               (if isearch-lazy-highlight-wrapped
                                   isearch-lazy-highlight-start
                                 window-end))
                        (max (or isearch-lazy-highlight-start-limit
                                 (point-min))
                             (if isearch-lazy-highlight-wrapped
                                 isearch-lazy-highlight-end
                               window-start))))

and that raises an error because `window-end' is nil.

Dunno what the right fix is.  Definitely min and max should not be
called if one of their args is nil.  What should be done in this case?

And I wonder, even if that error gets prevented, why we should update
lazy highlighting on a window other than the selected one?  Is that TRT?
In this case, at least, that other window has nothing to do with the
action in question (my code that calls `isearch-lazy-highlight-update'),
and there is no search in progress in that other window and no
lazy-highlighting (e.g. overlay) showing there.


In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor `Microsoft Corp.', version 10.0.16299
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''