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

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

> > 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 ()))

Good to know that.  But see also the bug(s) mentioned below.
Such advice will not suffice currently, for the reasons given
there.  There is neither the proper management of point nor
the proper lazy highlighting of the scrolled area.

But anyway, I am not looking for a way for an individual user to
advise the code - in this case, dynamically neutering the
post-command scrolling limitation code.  That's not the point
(besides not being very elegant).

I am asking for a way for users to customize an option, namely
the already existing option `isearch-allow-scroll'.  I am asking
for two scroll-allowing behaviors, giving users an easy choice.

> 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))

I'm not asking how to define additional scrolling commands.  The
problem is not insufficient commands that can scroll.  The problem
is the limitation of what the scrolling behavior is.

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

Note the question (which I answered): Why does this restriction,
which generally makes sense for general Emacs, NOT necessarily make
sense for Isearch.

Is this your answer to that question (?):

> 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.

I gave a reason why it should be different.  Or rather, why it
should be allowed to be different (au choix).

You gave no reason - you just repeated that it should be the same.
At most, you gave the same reason as for Emacs in general, which I
explained is not so relevant here.  That is, it is not cut & dried.

Some users can well prefer to be able to see more context, for the
reasons I gave.  And that is not so confusing as it is for general
Emacs, for the reasons I gave - in particular, resumption from the
same search position, with attendent automatic window return to
that position.

In Emacs in general, if scrolling moved beyond point, and if there
were nothing that brought the window back to point when you acted
at point (e.g., when finished temporarily scrolling) then you
would not see what was happening at point.  That would not be good
at all, under any circumstances.

But even in Emacs in general, if there were such an thing as 
temporary scrolling, with a well defined finish, and if the window
were then automatically restored to show point, which *did not
change* by scrolling, that too would not be so confusing.  We do
not have such a temporary-scrolling behavior in Emacs in general,
however.

You cannot reasonably compare general Emacs, without any such
temporary scrolling and window restoration, with what I proposed
for Isearch.  Apples & oranges.

> > 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.

I think you are suggesting that the search position should change
when you make use of the temporary scrolling?  If so, I strongly
disagree.

From my point of view, the current search hit (i.e., point) does
not change now, and it should never change, when you scroll.
The only thing that would change with my proposal is what is
shown in the window.  The scrolling would be temporary, and when
search is resumed the window would be restored to where it will
show the current search hit again.

What should happen if, after scrolling, a user quits Isearch?
For that case we have a design choice: either move point to
somewhere inside where the window is currently (scrolled), or
move the window back to show the current search hit, i.e.,
point (which has not changed).

I would be in favor of the latter.  I think the former possibility
would be problematic.  Move point to which position in the window,
for instance?

I'm open to suggestions about that.  But a priori, I would suggest
that in all cases when scrolling is done during Isearch the window
be restored to show the current search hit.

I feel more strongly about resumption of search after scrolling:
it should definitely continue where it was.  I think (less
strongly) that if search is quit after scrolling then the behavior
should be the same as quitting at the current search position.

> > 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.

That's exactly what I suggested.  Non-nil always means allow
scrolling, and the particular non-nil value would specify the
scrolling behavior: limited or not.  But see above and below about
what unlimited scrolling behavior should be like (highlighting, and
no change in point).
 
> > 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.

I cannot speak to the implementation - whether it is better to
highlight the whole buffer or just the part that is currently visible.
I would imagine that the latter is better, especially for large
buffers.  But I'm no expert on the implementation of Isearch.

I can say that without the continuation of lazy highlighting into the
scrolled area (e.g., what happens with your advice, above), there is
little use to scrolling.  The point of scrolling is, especially, to
see search hits farther down or up the buffer.

3. I just noticed the following problem (emacs -Q).  I can file a
separate bug report for it, if you prefer.

a. Set `isearch-allow-scroll' to t.

b. Go to the middle of a long (multi-screenful) buffer, such as
isearch.el.

c. Search for something common, such as "ear".

d. `C-v' a couple times, until you hit the limit.

e. `M-v' repeatedly.  There is no such limit in this direction.
Why not?  There should be.  Not really consistent for the user.

f. `C-v'.  The entire window fills with face `isearch' (which should
be only for `ear' search hits).

Both (e) - its difference from (d) - and (f) seem like bugs to me.

With my request (#1), both `C-v' and `M-v' would allow unlimited
scrolling.  And the current search position would not change by
scrolling.

It seems that currently `M-v' (past what should be the limit)
changes the search position.  Whether that's a third bug - call it
(g) or is part of the (e) behavior I don't know.

And that is also the behavior for `C-v' when I advise the
post-command hook as you suggested: point is kept in the window,
instead of staying at the current search hit.  Isearch behavior
should always be that point remains at the current search hit.

IMO, when scrolling is restricted, that restriction should apply
to both `C-v' and `M-v', and the search position should not change.
When scrolling is not restricted (request #1), that non-restriction
should apply to both `C-v' and `M-v',  and the search position
should (still) not change.