bug#15839: 24.3.50; `isearch-allow-scroll': be able to scroll point off screen temporarily

[Juri Linkov]

> 1. Non-nil `isearch-allow-scroll' lets you use a scroll command
> (e.g. `C-v') without exiting Isearch.  Unfortunately, this is coupled
> with the hard-coded behavior that you cannot scroll far enough in either
> direction that point would be moved off screen.

You can do what you want with just:

  (advice-add 'isearch-post-command-hook :override (lambda ()))

And if you want more commands to escape this restriction:

  (mapc (lambda (c) (put c 'isearch-scroll t))
        '(forward-char backward-char right-char left-char
          forward-word backward-word right-word left-word
          forward-sexp backward-sexp forward-paragraph backward-paragraph
          move-end-of-line end-of-visual-line move-beginning-of-line
          beginning-of-visual-line next-line previous-line))

> That restriction is general for Emacs, and it generally makes sense.
> It does not necessarily make sense during Isearch, however.  Why?

Because it is too confusing for users.  This is like leaving point
in one place, and scrolling without changing the position of point
(with inactive Isearch).  Isearch should not be different from the
default Emacs behavior.

> It's a bit like using `C-SPC' in a buffer, scrolling up a couple of
> screenfuls to look at something, and then using `C-u C-SPC' to return.
> But in Isearch there is no need for `C-SPC' or `C-u C-SPC': the search
> position is recorded.  Search resumes from that same position, no
> matter how far away one might have scrolled.

It makes sense to resume search from a new position like you can see
using code above.

> The enhancement request is to let users choose whether non-nil
> `isearch-allow-scroll' should limit you to scrolling only enough to keep
> point in the window or should not limit you.  This could be done by
> recognizing different non-nil values.

Maybe a new option of `isearch-allow-scroll' could allow this.

> 2. What's more, the lazy highlighting of search hits is even more
> limited currently.  When you scroll to the current limit, there can be
> lots of search hits that are not highlighted.

When scrolling outside the window boundaries will be allowed then
lazy highlighting should highlight the whole buffer so you could see
all matches when you quickly scroll the buffer.  But in this case
lazy highlighting will become more like hi-lock mode.