emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Wiegley
Subject: Re: Framework extending window functions for Follow Mode (etc.).
Date: Tue, 10 Nov 2015 14:29:18 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin)

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

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.

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?

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?

John



reply via email to

[Prev in Thread] Current Thread [Next in Thread]