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

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

> > I don't want to customize one variable to be able to
> > scroll farther, and another variable to have what's
> > shown by that scrolling have lazy-highlighting
> > (especially if the latter requires lazy-highlighting
> > the entire buffer, rather than just what I see when
> > scrolling).
> 
> Fine.  If you are lazy to customize two variables,
> after you customize one variable we could automatically
> change the value of the second variable.

That was not my point.

First is a question: Would customizing those two
variables in that way affect ONLY the specific
behavior I requested?  I don't expect so.

But even if the answer to that question is yes,
it's not clear from the descriptions of those
variables that that behavior follows as the only,
specific behavior.

If you implement code that does what I requested,
providing a single place for users to control it
(which should logically be `isearch-allow-scroll',
I think) - and that controls only it (does not
affect some other behavior) that will be great.

(Maybe you've done that - if you say so then I'll
take a closer look.)

IOW, how that implementation gets done under the
covers is not so important to a user.  If it's
best that it somehow make use of existing code -
even existing user options, that's OK.

It's not clear to me that the purpose of those
two variables is to realize the feature requested
here.  Is it, really?

But users should preferably not need to worry
about variable interactions.  The doc for a given
variable should make clear just what it does, and
each variable should preferably have one behavior
(per value chosen).

You should not, e.g., discover that by choosing a
var value to make a background red you have also
inadvertently turned off the ability to have blue
foreground text.

> > I want to be able to use `isearch-allow-scroll' to
> > let me scroll as far as I want, and see search hits
> > lazy-highlighted in what parts of the buffer I
> > scroll to.
> 
> Fine, we could allow the same feature to be enabled
> by two different variables.
> 
> @@ -2747,8 +2747,15 @@ isearch-allow-scroll
>    "Whether scrolling is allowed during incremental search.
>  If non-nil, scrolling commands can be used in Isearch mode.
>  However, the current match will never scroll offscreen.
> +If `unlimited', the current match can scroll offscreen.

Those last two sentences should be rephrased in
the usual manner: `unlimited' means... Any other
non-nil value means... 

> +This has the same effect as the value `nil'
> of `search-exit-option'.

Does it really?  If that's the only effect of
`search-exit-option' then yes, we don't need a
separate option.  But if that were true then
why did `search-exit-option' exist previously,
and why didn't it do this previously?  And why
was it called `search...' and not `isearch...'?

I'm guessing that nil `search-exit-option' does
not just have "the same effect".  But (see above)
even if it does, that doesn't mean that option
`search-exit-option' has the same effect, because
setting it to non-nil, ONLY to NOT have the
effect of `unlimited' `isearch-allow-scroll',
would presumably also have some other effect
unrelated to allowing scrolling.

Sorry that I'm arguing from ignorance here so
far, and not bothering to get informed in detail
about these existing options.

I'm essentially guessing that trying to repurpose
some combination of them to achieve this request
is not a great idea.  If I'm wrong, please try to
present the counter argument straightforwardly.
I'm open to being convinced, but a first sense is
that this is likely not the right approach.

If you just tell me I'm wrong then I'll take a
closer look at what you're proposing.  But first
please consider what I say here, in case it's
valid.

>  If nil, scrolling commands will first cancel
>  Isearch mode."

BTW, why do we say "first" there?  First before
what?  There is no other action after this, is
there?  I.e., there is no "second" or "and" that
follows this "first", right?  Or is there some
additional context that makes that "first" mean
something?

Thanks for working on this.  Let me know, if you
think I'm wrong and should just take a closer
look at what you've proposed.