Re: Framework extending window functions for Follow Mode (etc.).

[Alan Mackenzie]

Hello, John.

It's getting late, but seeing as how we're nine hours' timezones apart,
I'd like to get this out tonight.

On Tue, Nov 10, 2015 at 02:29:18PM -0800, John Wiegley wrote:
> >>>>> Alan Mackenzie <address@hidden> writes:

> >> Adding your proposal to the Emacs Wiki Proposals page
> >> (http://www.emacswiki.org/emacs/Proposals) would be a good way to liberate 
> >> the
> >> current state of your work from this lengthy discussion, so I can look at 
> >> it
> >> again with fresh eyes.

> > Done.

> Great proposal. I have an idea about this functionality I'd like to suggest.

> Right now we have a set of functions with well-defined behavior. Under certain
> conditions of use, those functions are too specific. You'd like to change the
> functions' API so that some packages (follow-mode) can change what they mean,
> and requiring other packages (isearch) to explicitly allow the override.

> Maybe the problem is that we've turned object-orientation inside out. What we
> really care about is not the set of functions, but the notion of what "current
> window" means. It needs to be broader in scope when follow-mode is active, to
> address the notion that multiple windows are being knit together, visually. It
> has nothing to do with isearch, so ideally the change shouldn't affect it.

If only we lived in an ideal world.  ;-)

> What if we just had `window-start-function', receiving the window as its
> argument -- effectively having getter and setters on window objects. Could
> follow-mode determine from the argument whether the window was involved in its
> "group", and act accordingly? That would avoid API changes, is cheaper to do,
> and no modes would have to change.

Follow Mode could indeed determine this.  However, expecting everything
else just to work is being too optimistic.  The display engine and Follow
Mode fight each other, to some extent.  Follow Mode, for example,
continually monitors where point it, and thus which window it is
logically in.  It then puts point physically into that window, preventing
the display engine from messing everything up.  For example.

If things aren't done very carefully, display artefacts ruin the effect.
I had to diagnose and correct one of these in Isearch.  The cause was
point being in the wrong place at the wrong time.

Also, Follow Mode would need access to the raw `window-start', etc.,
since it has to manipulate each window individually, so this would
need some extension of the existing interface anyway.

> That is:

>           window-start WIND
>     calls (funcall window-start-function WIND)
>     calls window-object-start WIND

> So the current window-start is renamed to window-object-start (or some
> internal sounding name), which is reached by indirecting through the variable
> window-start-function.

> I wonder, though, if such extensibility is worth the extra layer of
> indirection. It feels a bit... special-cased and not very elegant, maybe? Do
> we care enough about follow-mode to make a core change like this?

Things like window-start are C primitives, and called a lot from other C
code.  They really have to stay basically as they are.

The abstraction created by Follow Mode is really rather fragile.  I do
not feel that trying to make such an automatic "object-like" solution
would be a good idea, though I haven't thought it through thoroughly,
yet.  (A lovely bit of linguistic contrast, no?)

Still, you've been giving me ideas.  The ideal place to implement Follow
Mode would be inside the display engine, mainly in C.  Then we could
truly treat a "multiple" window as a single object.  Such a "multiple"
window could, for example, have a single (vertical) scroll bar and
possibly a single mode line.  Although it wouldn't be all that easy to
implement, it probably wouldn't be as difficult as all that.  I'm
guessing it would take longer than Friday 13th November to finish,
though.

> It could also be that we're looking too much at a specific solution, by
> needing window-start to change its meaning in order to support correct
> behavior by isearch. Is there a screencast anywhere, so I could see what
> follow-mode with isearch looks like using your patch, and what it looks like
> without the patch? Is anyone else using this code?

No, but a screen shot wouldn't really be helpful.  It's behaviour rather
than appearance that matters here.  A video would be the best thing, if I
had the technology to make one.  Maybe the best thing would be for me to
make the patch available in some fashion so that you can try it out.  The
total size of the two patches is currently ~1700 lines (About 350 lines
for Isearch, and 1350 lines for the framework, including documentation
changes).  As yet, nobody else is using it.  The patch has not yet left
my PC (apart from backup copies).

> John

-- 
Alan Mackenzie (Nuremberg, Germany).