Re: bug#17453: Isearch doesn't work properly with Follow Mode.

[Alan Mackenzie]

Hello, Eli.

On Sun, Nov 01, 2015 at 10:54:21PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 1 Nov 2015 18:27:33 +0000
> > Cc: address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>

> > > How is this "not having isearch know about Follow mode"?  I see that
> > > knowledge on every step of this patch, whenever you call the new
> > > functions.
> > 
> > It has no knowledge of the internals of Follow Mode.

> > Follow Mode itself choses which window to leave point in.  For example,
> > if isearch started in the left hand window, FM will place point in the
> > RH window if the first match is there.

> That's not what I see.  What I see is that starting Isearch in the
> left window scrolls that window, and then the right window scrolls
> accordingly.

That is one of the bugs that my patch to isearch.el solves.  But I think
Juri has knocked that one down already.  It is caused by a glitch in
lazy highlighting.  Disable lazy highlighting, and try it again.  Then
C-s will move onto the next window rather than scrolling the one it
started on.

> In any case, what I thought you'd do is introduce a bunch of
> variables, such as window-selection-for-scroll-function, that will
> allow Follow mode to override the default (trivial) value and dictate
> its own decisions to its clients.  Or something like that.

> > window*-start and friends do constitute a generic framework.

> No, a generic framework would be, for example, to have a variable
> whose value is a function, and let Follow mode override the default
> value.

That's precisely what I've done (but haven't submitted for review, yet).
In window.el, I've got code like this:

  (defvar window*-start-function #'window-start)
  (make-variable-buffer-local 'window*-start-function)
  (put 'window*-start-function 'permanent-local t)
  (defun window*-start (&optional window)
    "Return position at which display currently starts in the group of
  windows containing WINDOW.  When a grouping mode (such as Follow Mode)
  is not active, this function is identical to `window-start'.

  WINDOW must be a live window and defaults to the selected one.
  This is updated by redisplay or by calling `set-window*-start'."
    (funcall window*-start-function window))

, and `follow-mode' sets window*-start-function to its own value when FM
is started, and kills the buffer local value when FM is disabled.

I think there's been some miscommunication over our last few posts.
Sorry about that.

> > > Btw, I see no reason to introduce new functions.  Instead, we could
> > > have the original ones accept an additional optional argument.

> > We could.  But that might make these functions less "pure": as well as
> > doing what they do, they would also have to execute some call-out to
> > Follow Mode in some fashion.

> Isn't that what window*-* functions do anyway?  Where's the benefit?

Maybe there isn't really any.  I don't feel too strongly about it.  But
what would the optional extra parameter to window-start be called?
"group"?

It would mean the facility having to be coded in C rather than Lisp.  I
suppose that's not too difficult.  It would save having to have the
rather ugly names with "window*" in them.

> > > You are right about not relying on the list, but window-next-sibling
> > > and window-prev-sibling are available, and always will be, so you can
> > > "trivially" use them instead of relying on a list.

> > The next/previous sibling might be displaying a different buffer.

> But that's very easy to test, no?

Yes, but it would be duplicating what Follow Mode has already done in
one of its hooks (post-command-hook, I think).  FM caters for any
arrangement of windows in a frame (not only side by side, but over
eachother, or a mixture) just like Emacs does.  Maybe they have the same
notion of order of windows, maybe they don't.  In the general case
(which surely doesn't happen in practice much), we'd have to scan the
frame's window tree more carefully.

> > to use window-next/previous-sibling properly would mean some fairly
> > extensive changes to the innards of Follow Mode - FM has its own
> > left-to-right, top-to-bottom algorithm for ordering its windows.

> What algorithm could that be, if not something that traverses the
> window tree in some order?

IIRC, FM takes the coordinates of the top left corner of each pertinent
window, and sorts them top to bottom first, then left to right for any
windows with the same Y coordinate.  Or something like that.

> > > If you agree, then John's question still stands, I think.

> > The "car of a list of windows" he was talking about means that list of
> > windows needs to come from somewhere.  The list is maintained by Follow
> > Mode, really only available using an internal FM function.  As soon as
> > we use this, we have coupled isearch with Follow Mode more tightly.
> > This is undesirable.

> Not if you go through a variable whose default value Follow mode can
> override.  Or some other decoupling technique like that, I'm sure
> there are more, perhaps more elegant ones.

I suppose so.  But why should isearch have to know that it is the car of
the list which is the "first" window (for window*-start)?

-- 
Alan Mackenzie (Nuremberg, Germany).