RE: Should ending successful Isearch with C-g restore the relative window position?

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

> > That patch did not fix the problem when searching across Info nodes.
> > The attached patch does.  AFAICT, it works generally.
> 
> A more general approach would be to save the window start position
> on the stack and restore it in `isearch-cancel' like the patch 
> below does.

AFAICT, your slightly more complicated code has the same effect as mine.  Yes,
it adds `window-start' to the state struct, but I don't see any particular
advantage.  Is there some case it handles better?

> `isearch-done' already does something like this by restoring
> the original window configuration with `set-window-configuration'
> from `isearch-window-configuration'.  But it does this only
> on slow terminals where baud-rate is less than 1200.

That code was in fact my starting point, when looking at fixing this.

I almost filed an bug report (enhancement request), wondering whether we might
want the relative positions of point in each window to be saved as part of a
window configuration.  (Still wondering whether that might be a good idea.)

> So perhaps this patch will also make `isearch-window-configuration' obsolete.

I don't see how.  How is it relevant to what that code does?  That code does not
save/restore `window-start' or the window-relative cursor position, and your
patch (like mine) does not save/restore the window config.

(But I wonder whether that code might be obsolete anyway, in the sense of not
being used at all anymore.)

> The remaining problem is how to take into account the case
> when `isearch-allow-scroll' is non-nil and the user scrolled the
> window-start to another position.

I don't understand the problem.  With either my patch or yours, non-nil
`isearch-allow-scroll' seems to DTRT, AFAICT.  You can scroll using `C-v', mouse
wheel, etc. during Isearch, and if you hit `C-g' to cancel searching then you
get back where you started, including cursor position relative to window.  Works
everywhere I've tested, including across nodes in Info.

Can you give a recipe illustrating the problem you see?

> We should find the right place to update the window-start of the
> previous state on the search stack to be able to restore it later.

See above.  I don't understand what the problem is.  Seems to work OK as is.