bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window

[Anders Lindgren <andlind@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3897 bytes --]

Hi again!

In addition to the problems I originally reported, I realized today that
the modification also made follow-mode place windows incorrectly, which
indicates that some primitive display-related function returns incorrect
values.

Do you want me to report a new bug, or should we see this as a second
symptom?

You can verify this by doing the following steps:

    emacs -Q
    C-h t
    M->
    M-x follow-delete-other-windows-and-split RET
    C-p
    C-p

After the second C-p, the left window is recentered, which is shouldn't.
This typically occurs when follow-mode thinks the point is not visible in
any window, which probably is due to incorrect values being reported from
primitive functions. (For example, in bug #15957 `window-end' didn't honour
it's FORCE argument, since some display functions didn't mark the end value
as being dirty.)

I will try to track this down in more detail. However, I wanted to give you
a heads up since it's appears as though you are close to a release -- it
might take me a couple of days to find the problem, as I have very limited
time to spend on Emacs-related things.

Sincerely,
    Anders Lindgren



On Fri, Dec 13, 2013 at 6:55 PM, Anders Lindgren <andlind@gmail.com> wrote:

> Hi!
>
> I agree that we would need to find out why the patch makes Emacs slow. (In
> fact, I only supplied the information about the internals of follow-mode to
> help you track down the problems with the slowdown.)
>
> However, I don't agree with Eli -- it is possible to place window-start at
> point-max! However, there is code in the display engine that explicitly
> recenters such windows, after a while, or when something happens. For
> example:
>
>      emacs -Q
>      C-x 3
>      C-x o
>      M-: (set-window-start (selected-window) (point-max)) RET
>      C-x o
>      M-<
>      blablabla     (type some text)
>
> As you type text in the left window at the beginning of the scratch
> buffer, the right window is recentered. Follow-mode needs its windows to
> stay put (even the empty ones), as this is essential in creating the
> illusion that a number of windows make up a very tall virtual window.
>
> When I originally wrote follow-mode (some 18 years ago), I suggested to
> the Emacs maintainers to add a feature to make the recentering of empty
> windows conditional, so that follow-mode could control this. However, at
> the time they were not interested so I continued with the current system,
> which has worked flawlessly since then.
>
> If you are interested in making the change in the display engine,
> follow-mode should of course be rewritten to use it. Otherwise, I suggest
> that we keep it as it is today -- solutions using overlays etc. don't
> appeal to me at all.
>
>     -- Anders
>
>
>
> On Fri, Dec 13, 2013 at 5:38 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:
>
>> > I am the original author of follow-mode, so I can share one interesting
>> > implementation detail. When the viewed buffer ends before the last
>> window,
>> > follow-mode tries to display this window without any content (by setting
>> > the window start to point-max). Unfortunately, the Emacs display engine
>> > always tries ensure that windows are not empty so it repositions it...
>> So,
>> > follow-mode hammers in its view of the world every chance it gets,
>> > currrently in post-command hook and window-scroll-functions.
>>
>> Hmm.. so we have 2 things to do:
>> 1- figure out why my patch slowed things down so much.
>> 2- change follow-mode to use a different approach.  Maybe a good way is
>>    to do the following: put window-point at point-max, and add an overlay
>>    on window-start...point-max that makes the text invisible (with
>>    a `window' property, so it's only invisible in that window).
>>    Of course, maybe that won't work either.  But hooking everywhere
>>    doesn't sound like a good idea.
>>
>>
>> -- Stefab
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5171 bytes --]