From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#32839: 27.0.50; recenter doesn't redisplay Date: Sun, 30 Sep 2018 09:22:11 +0300 Message-ID: <838t3j5wto.fsf@gnu.org> References: <8736txjvkg.fsf@mail.linkov.net> <83lg7p8hnf.fsf@gnu.org> <87va6tb8lo.fsf@mail.linkov.net> <83k1n895qv.fsf@gnu.org> <87tvmbq2pp.fsf@mail.linkov.net> <835zyr8mn8.fsf@gnu.org> <875zyqwnrb.fsf@mail.linkov.net> <83k1n66t0w.fsf@gnu.org> <87k1n3c0vo.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1538288472 4110 195.159.176.226 (30 Sep 2018 06:21:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 30 Sep 2018 06:21:12 +0000 (UTC) Cc: 32839@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 30 08:21:08 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6V6J-0000xj-Sj for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Sep 2018 08:21:08 +0200 Original-Received: from localhost ([::1]:53893 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6V8Q-0005gK-BL for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Sep 2018 02:23:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6V8I-0005gE-DQ for bug-gnu-emacs@gnu.org; Sun, 30 Sep 2018 02:23:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6V8C-00025E-UQ for bug-gnu-emacs@gnu.org; Sun, 30 Sep 2018 02:23:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55105) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g6V8A-000232-3E for bug-gnu-emacs@gnu.org; Sun, 30 Sep 2018 02:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g6V89-00071g-Te for bug-gnu-emacs@gnu.org; Sun, 30 Sep 2018 02:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Sep 2018 06:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32839 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32839-submit@debbugs.gnu.org id=B32839.153828855126958 (code B ref 32839); Sun, 30 Sep 2018 06:23:01 +0000 Original-Received: (at 32839) by debbugs.gnu.org; 30 Sep 2018 06:22:31 +0000 Original-Received: from localhost ([127.0.0.1]:59363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6V7f-00070k-CF for submit@debbugs.gnu.org; Sun, 30 Sep 2018 02:22:31 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44225) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6V7e-00070Y-O6 for 32839@debbugs.gnu.org; Sun, 30 Sep 2018 02:22:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6V7W-0001mP-Ga for 32839@debbugs.gnu.org; Sun, 30 Sep 2018 02:22:25 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6V7V-0001m4-WA; Sun, 30 Sep 2018 02:22:22 -0400 Original-Received: from [176.228.60.248] (port=2078 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g6V7U-0005BY-Tt; Sun, 30 Sep 2018 02:22:21 -0400 In-reply-to: <87k1n3c0vo.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 30 Sep 2018 02:38:03 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:150784 Archived-At: > From: Juri Linkov > Cc: 32839@debbugs.gnu.org > Date: Sun, 30 Sep 2018 02:38:03 +0300 > > > List of functions to call before redisplaying a window with scrolling. > > ^^^^^^^^^^^^^^ > > But (info "(emacs) Recentering") says that recentering is scrolling: > > Typing ‘C-l’ twice in a row (‘C-l C-l’) scrolls the window so that > ^^^^^^^ > point is on the topmost screen line. Typing a third ‘C-l’ scrolls the > ^^^^^^^ > window so that point is on the bottom-most screen line. Each successive > ‘C-l’ cycles through these three positions. That's because C-l in most cases indeed scrolls, and I don't see a point in making the documentation much more complicated due to this special case. But if you think it's important enough, we could come up with some wording that would reflect the situation more accurately, or say things more vaguely. > So 'C-l C-l C-l' is eligible for the calls of window-scroll-functions. It's eligible, but its eligibility doesn't always materialize. Frankly, I'm not sure where this discussion goes. > I grepped for window-scroll-functions, and see that the current situation > is quite bad: > > 1. tabulated-list-window-scroll-function is not called on 'C-u -1 C-l' > when the last window line is fully visible, so it doesn't adjust > the width for display-line-numbers in this case. A bug report with a recipe would be appreciated. > 2. linum-mode relies more on post-command-hook because > window-scroll-functions is not reliable. > > 3. erc-scroll-to-bottom was forced to replace window-scroll-functions > with post-command-hook because window-scroll-functions doesn't > support altering the way the window is scrolled. Like I said a few days ago: the hooks provided by the display engine cannot possibly be as accurate as you expect, because the display engine doesn't know enough about the application, and its main purpose is to redraw the screen as cheaply as possible. The correlation between what the display engine does and higher-level concepts like "scrolling" can be quite low in some cases, because "scrolling" means something very different to the display engine than what it means to users and Lisp programs. > The only hope to fix these problems and to close this report is to call > the new hook window-state-change-functions at the very end when the > redisplay is completely finished "Redisplay is completely finished" is not well defined. Especially since some (most?) hooks only care about a specific window, whereas redisplay considers more than one window. Moreover, what would be the purpose of such a hook? It can tell nothing about what was done to perform redisplay. For example, if the display engine decided that the single displayed window didn't need to be redrawn at all, the "redisplay completely finished" hook will still be called, yes? > probably at the same time when post-command-hook is called. That hook is not called from the display code. But in any case, if post-command-hook is what you want, just use it. Why do we need another hook at the same place? It sounds redundant.