From: Anders Lindgren <andlind@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>
Cc: 16129@debbugs.gnu.org
Subject: bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window
Date: Thu, 2 Jan 2014 19:39:21 +0100 [thread overview]
Message-ID: <CABr8ebYPj2y0wAYRnJCziupGx4GjequDXZVt6FkwGbQXKxC+Sg@mail.gmail.com> (raw)
In-Reply-To: <CABr8ebaOj992z1tg_taR0=MmieoTRcTq9cEwogs9xtKM1t1Q1A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5728 bytes --]
Hi again!
I've dug a bit more into this. It looks like it's not follow-mode that
repositions the window, instead I guess it's some kind of recentering code
in the display engine that have gone "crazy".
I've managed to reproduce the problem with an extremely cut-down version of
the code, which simply reads and restores window-start of windows when
windows-start is point-max.
To reproduce, do the following:
emacs -Q
Enter and evaluate the following:
(defun my-avoid-tail-recenter (&rest _rest)
(let* ((orig-buffer (current-buffer))
(top (frame-first-window))
(win top))
;; If the only window in the frame is a minibuffer
;; window, `next-window' will never find it again...
(unless (window-minibuffer-p top)
(while
(let ((start (window-start win)))
(set-buffer (window-buffer win))
(if (eq (point-max) start)
;; Write the same window start back, but don't
;; set the NOFORCE flag.
(set-window-start win start))
(setq win (next-window win 'not t))
(not (eq win top)))) ;; Loop while this is true.
(set-buffer orig-buffer))))
(add-hook 'post-command-hook 'my-avoid-tail-recenter)
C-x 3
M-: (set-window-start (selected-window) (point-max)) RET
C-x o
C-p
Here, the window will be recentered without there being any reason for it.
Note that this will apply to any window in any frame, as long as there is a
window where window-start == point-max, even if the window displays a
different buffer.
As this now falls outside of follow-mode, I think that I have reached the
end of what I can contribute...
Sincerely,
Anders Lindgren
On Thu, Jan 2, 2014 at 2:55 PM, Anders Lindgren <andlind@gmail.com> wrote:
> 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: 8230 bytes --]
next prev parent reply other threads:[~2014-01-02 18:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 14:34 bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window Anders Lindgren
2013-12-13 15:32 ` Eli Zaretskii
2013-12-13 15:36 ` Eli Zaretskii
2013-12-13 16:38 ` Stefan Monnier
2013-12-13 17:55 ` Anders Lindgren
2014-01-02 13:55 ` Anders Lindgren
2014-01-02 18:39 ` Anders Lindgren [this message]
2014-01-05 23:13 ` Anders Lindgren
2014-01-06 3:45 ` Eli Zaretskii
2014-01-06 8:20 ` Anders Lindgren
2014-01-06 16:33 ` Eli Zaretskii
2014-01-07 8:13 ` Anders Lindgren
2014-01-10 9:31 ` Eli Zaretskii
2014-01-10 18:52 ` Anders Lindgren
2014-01-10 19:00 ` Eli Zaretskii
2014-01-13 11:41 ` Anders Lindgren
2014-01-13 14:47 ` Stefan Monnier
2014-01-13 16:16 ` Eli Zaretskii
2014-01-14 12:34 ` Anders Lindgren
2014-01-14 16:25 ` Eli Zaretskii
2014-01-16 12:24 ` Anders Lindgren
2014-01-16 14:42 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABr8ebYPj2y0wAYRnJCziupGx4GjequDXZVt6FkwGbQXKxC+Sg@mail.gmail.com \
--to=andlind@gmail.com \
--cc=16129@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.