bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Alan Mackenzie
Subject: bug#17453: Isearch doesn't work properly with Follow Mode.
Date: Sat, 31 Oct 2015 23:25:38 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, John.

On Sat, Oct 31, 2015 at 03:35:22PM -0700, John Wiegley wrote:
> >>>>> Alan Mackenzie <acm@muc.de> writes:

> > The new functions are window*-start, window*-end, set-window*-start,
> > recenter*, pos-visible-in-window*-p, move-to-window*-line, and sit*-for.

> > window*-start returns the window-start of the _first_ window in the group,
> > window*-end returns the window-end of the _last_ window in the group, and so
> > on, all these functions doing the Right Thing for a group of windows.
> > sit*-for exists, because Follow Mode needs a chance to resynchronise its
> > windows before redisplay happens.

> What is the reason for having separate functions such as window*-start,
> instead of just taking the car of a list of windows?  I may be missing some
> context here, but this sounds like special-casing general behavior, and I'm
> wondering why it's necessary...

The prime use case is in isearch.  At the moment isearch doesn't work
well when Follow Mode is active (try it!).

My first attempt at amending isearch for this involved manipulating
Follow Mode's list of windows directly inside isearch.el.  The result
was too close a coupling between isearch and Follow Mode, and was also
rather ragged.  Stefan rejected this patch, asking for a more abstract
solution.

What I am proposing now is a solution where any library which needs to
manipulate things like window positions will be trivially upgradable to
working with Follow Mode, merely by replacing `window-start' by
`window*-start', etc.

The fact that the "group" of windows is represented by a list is an
implementation detail to be encapsulated within follow.el.  In the
(fairly distant) future, this might perhaps be superseded by code in
redisplay.  Perhaps.

> John

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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