From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: charles@aurox.ch (Charles A. Roelli) Newsgroups: gmane.emacs.bugs Subject: bug#29325: 26.0.90: Info scrolling stuck Date: Tue, 21 Nov 2017 20:24:05 +0100 Message-ID: References: <83fu9ehuog.fsf@gnu.org> <83d14hidlk.fsf@gnu.org> <83r2sudwgv.fsf@gnu.org> <83r2ssd7eq.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1511292258 32530 195.159.176.226 (21 Nov 2017 19:24:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Nov 2017 19:24:18 +0000 (UTC) Cc: 29325@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 21 20:24:11 2017 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 1eHE9M-0007ZJ-PD for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Nov 2017 20:24:05 +0100 Original-Received: from localhost ([::1]:36181 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHE9T-0000z6-VI for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Nov 2017 14:24:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHE9N-0000z0-9R for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2017 14:24:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHE9K-0007B8-2N for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2017 14:24:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42727) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eHE9J-0007B1-VU for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2017 14:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eHE9J-0000EI-MD for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2017 14:24:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: charles@aurox.ch (Charles A. Roelli) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Nov 2017 19:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29325 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29325-submit@debbugs.gnu.org id=B29325.1511292198825 (code B ref 29325); Tue, 21 Nov 2017 19:24:01 +0000 Original-Received: (at 29325) by debbugs.gnu.org; 21 Nov 2017 19:23:18 +0000 Original-Received: from localhost ([127.0.0.1]:51408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHE8c-0000DF-8n for submit@debbugs.gnu.org; Tue, 21 Nov 2017 14:23:18 -0500 Original-Received: from sinyavsky.aurox.ch ([37.35.109.145]:49940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHE8a-0000D0-NW for 29325@debbugs.gnu.org; Tue, 21 Nov 2017 14:23:17 -0500 Original-Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 71181225CB for <29325@debbugs.gnu.org>; Tue, 21 Nov 2017 19:15:53 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= references:subject:subject:in-reply-to:to:from:from:message-id :date:date; s=dkim; t=1511291750; x=1512155751; bh=FotGhBDIZcArV pa2XiNC/Ym+3Kx08rqkdroc6Xj6W18=; b=l4eUP4tqaDPO3eB8ALECMnKD6t+GK N9gC5ACnxyxele7qA0Sm9neH1nUpBsYGs4NrwPt/5yGiofCgKnjNL4IlOMFRST0R f0/8swR0spqgH9NDwrk/Ib9aEtYZkgm56TsmmKmdGRkLVjiozj2fVMnZpcf6weg/ 2DFfu7P3MOA8cc= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Original-Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id apwy9W0StGmO for <29325@debbugs.gnu.org>; Tue, 21 Nov 2017 19:15:50 +0000 (UTC) Original-Received: from gray (125.85.192.178.dynamic.wline.res.cust.swisscom.ch [178.192.85.125]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id 672D8225C3; Tue, 21 Nov 2017 19:15:50 +0000 (UTC) In-reply-to: <83r2ssd7eq.fsf@gnu.org> (message from Eli Zaretskii on Mon, 20 Nov 2017 22:25:33 +0200) 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:140211 Archived-At: > Date: Mon, 20 Nov 2017 22:25:33 +0200 > From: Eli Zaretskii > > > Date: Mon, 20 Nov 2017 20:52:39 +0100 > > From: charles@aurox.ch (Charles A. Roelli) > > CC: 29325@debbugs.gnu.org > > > > I don't have access to a GNU/Linux system at the moment, but if I > > recall correctly, it would be 5 lines at a time, when scrolling > > slowly. > > Then I'd expect the same behavior to happen if you do "M-5 M-v" > instead of turning the wheel. Does it? It does. > Just to make sure we are not barking up the wrong tree: this is in > "emacs -Q" with no customizations of any scroll-related variables, > like scroll-margin, scroll-conservatively, etc., right? Yes, always from emacs -q. > Date: Sun, 19 Nov 2017 19:12:00 +0200 > From: Eli Zaretskii > > If you build with --enable-checking='yes,glyphs', and then turn on > redisplay tracing with "M-x trace-redisplay" before scrolling with the > wheel, what do you see? And how does that trace differ from when you > scroll with "M-1 M-v"? > > (I find it useful to disable blink-cursor-mode and global-eldoc-mode > before such experiments, because they tend to trigger extra redisplay > cycles that conceal the interesting parts.) Thanks again for this useful advice. What follows is the annotated output, according to the following recipe: > The behavior is different depending on how fast the mouse wheel is > turned. If it is turned slowly several times in a row, it is possible > to make window-start reach as far as the second or third line of the > buffer. If you turn it once more, then window-start jerks down a few > lines instead of reaching the start of the buffer. This can be > repeated ad infinitum. redisplay_internal 0 <= START FIRST SCROLL 0x1360330 (*info*): forced window start redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_internal 0 redisplay_internal 0 <= START SECOND SCROLL 0x1360330 (*info*): forced window start redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_internal 0 <= START THIRD SCROLL (BROKEN) redisplay_internal 0 0x1360330 (*info*): recenter redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_internal 0 The third scroll should have reached the start of the buffer, but recenters instead of doing so. Furthermore, I found that reverting the following commit fixes the issue locally, in a build of emacs-25: * 9135bd7..: Paul Eggert 2016-05-13 Improve display of tex-verbatim and Info quoted commit 9135bd7af7bdf9f805b185a77fe4e6d33dec4009 Author: Paul Eggert Date: Fri May 13 13:30:33 2016 -0700 Improve display of tex-verbatim and Info quoted Problem reported by Glenn Morris (Bug#19889). * doc/emacs/display.texi (Standard Faces): * doc/lispref/display.texi (Basic Faces): * etc/NEWS: Mention fixed-pitch-serif. * lisp/faces.el (face-font-family-alternatives): New family alias Monospace Serif. (fixed-pitch-serif): New face, which uses the new family. * lisp/info.el (Info-quoted): * lisp/textmodes/tex-mode.el (tex-verbatim): Use the new face. * test/lisp/legacy/font-parse-tests.el (font-parse-tests--data): Add test case for Monospace Serif. This is backport from master (cherry picked from commit 36906806ccfc0e53f1d8c365ab0d7151288b7833) doc/emacs/display.texi | 3 +++ doc/lispref/display.texi | 1 + etc/NEWS | 5 +++++ lisp/faces.el | 29 +++++++++++++++++++++++++++++ lisp/info.el | 2 +- lisp/textmodes/tex-mode.el | 3 +-- test/automated/font-parse-tests.el | 1 + 7 files changed, 41 insertions(+), 3 deletions(-) So it may be that the new choice of fonts exposes a bug in the scrolling mechanism. Finally, I tried to make some analysis (by setting a breakpoint on function "redisplay_window" in GDB) of why the recentering happens while scrolling. I then did the same analysis after having checked out the commit prior to the problematic one, and compared the code path. It may well be of no use, but I include it here in case: When causing the problematic behavior, redisplay_window reaches try_to_scroll via this if statement: if (!cursor_row_fully_visible_p (w, false, false)) { /* Point does appear, but on a line partly visible at end of window. Move it back to a fully-visible line. */ new_vpos = window_box_height (w); /* But if window_box_height suggests a Y coordinate that is not less than we already have, that line will clearly not be fully visible, so give up and scroll the display. This can happen when the default face uses a font whose dimensions are different from the frame's default font. */ if (new_vpos >= w->cursor.y) { w->cursor.vpos = -1; clear_glyph_matrix (w->desired_matrix); goto try_to_scroll; } } That is, (!cursor_row_fully_visible_p (w, false, false)) and (new_vpos >= w->cursor.y) evaluate to true. try_to_scroll looks like this: try_to_scroll: /* Redisplay the mode line. Select the buffer properly for that. */ if (!update_mode_line) { update_mode_line = true; w->update_mode_line = true; } if ((scroll_conservatively || emacs_scroll_step || temp_scroll_step || NUMBERP (BVAR (current_buffer, scroll_up_aggressively)) || NUMBERP (BVAR (current_buffer, scroll_down_aggressively))) && CHARPOS (startp) >= BEGV && CHARPOS (startp) <= ZV) { /* The function returns -1 if new fonts were loaded, 1 if successful, 0 if not successful. */ int ss = try_scrolling (window, just_this_one_p, scroll_conservatively, emacs_scroll_step, temp_scroll_step, last_line_misfit); switch (ss) { case SCROLLING_SUCCESS: goto done; case SCROLLING_NEED_LARGER_MATRICES: goto need_larger_matrices; case SCROLLING_FAILED: break; default: emacs_abort (); } } /* Finally, just choose a place to start which positions point according to user preferences. */ recenter: #ifdef GLYPH_DEBUG debug_method_add (w, "recenter"); #endif ... However, these checks are all false during the scroll: (scroll_conservatively || emacs_scroll_step || temp_scroll_step || NUMBERP (BVAR (current_buffer, scroll_up_aggressively)) || NUMBERP (BVAR (current_buffer, scroll_down_aggressively))) so control falls through to the "recenter" label. When I execute the same scroll command (from the same point and window scroll state) in the commit prior to the problematic one, then the if expression, if (!cursor_row_fully_visible_p (w, false, false)) evaluates to false instead, control flow leads elsewhere, and the bug does not happen.