From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: The unwarranted scrolling assumption Date: Fri, 18 Jun 2010 10:54:53 +0300 Message-ID: <838w6cixma.fsf@gnu.org> References: <87ocfcj7r4.fsf@mail.jurta.org> <87631jvpzg.fsf@gmail.com> <4C18211C.3070106@harpegolden.net> <87vd9j5neu.fsf@kfs-lx.rd.rdm> <83sk4misf2.fsf@gnu.org> <83iq5hiiin.fsf@gnu.org> <83fx0lihov.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1276847961 25178 80.91.229.12 (18 Jun 2010 07:59:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 18 Jun 2010 07:59:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 18 09:59:18 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OPWTu-0003j4-4x for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 09:59:18 +0200 Original-Received: from localhost ([127.0.0.1]:49568 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPWTt-0000pG-C5 for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 03:59:17 -0400 Original-Received: from [140.186.70.92] (port=51408 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPWPb-0006k6-TN for emacs-devel@gnu.org; Fri, 18 Jun 2010 03:54:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPWPa-00024K-Hs for emacs-devel@gnu.org; Fri, 18 Jun 2010 03:54:51 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:34069) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPWPa-00023t-BB for emacs-devel@gnu.org; Fri, 18 Jun 2010 03:54:50 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L4700E009Z6UT00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 18 Jun 2010 10:54:48 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.88.125]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L4700ELC9ZB3T20@a-mtaout20.012.net.il>; Fri, 18 Jun 2010 10:54:48 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:126132 Archived-At: > From: Lennart Borgman > Date: Fri, 18 Jun 2010 00:16:33 +0200 > Cc: emacs-devel@gnu.org >=20 > > Again, PLEASE answer my questions, if you really want my help in > > understanding this issue. =C2=A0What parts of the above condition= prevented > > reconsider_clip_changes from resetting b->clip_changed to zero? = =C2=A0If > > needed, please re-run under GDB (without your patches) and see wh= at > > other factors are at work here. >=20 > I can now answer you question again since I have found a new way to > make "jumping scrolling" appear. However the situation above is not > involved, at least not directly, since ->clip_changed is 0. (I thin= k > there is an unused global variable clip_changed that is not used.) So what you describe is a different situation altogether, and doesn't help to understand your original report and the patch that is suppose= d to fix it. Emacs uses the recenter as the last resort, and it does this in many different situations. Discovering another situation where it happens does not help to understand the one you discovered before, and the patch to correct it (assuming we want that) might be entirely different. This just adds confusion. > The situation is now this: > - I am using my patch (in the state I sent it here). > - I have seen no problem with the patch (but as I said I think ther= e > is one problem though it has not shown up). > - It is quite hard to make Emacs do the "jumping scrolling". >=20 > So it is better, still there are problems. It may be "better" in the use-cases you tried. But without understanding the original problem and why your patch fixes it, it is quite likely that the patch will introduce other redisplay problems. So I don't think we should accept this patch without understanding what problem causes the recentering in the original situation you reported. > - Then if I just hold down the down arrow it can happen after a whi= le. > - My output shows that it is because try_scrolling failed. try_scrolling may legitimately fail in some cases. > Some variables as I see them now at the recenter: label in redispla= y_window: > scroll_step =3D=3D 1 > temp_scroll_step =3D=3D 0 > current_buffer->clip_changed =3D=3D0 Why current_buffer, there = is a > variable buffer here? > current_buffer->scroll_up_aggressively =3D=3D 45459482, same down >=20 > BTW, the use of current_buffer here seems to me to be a bug. No, it isn't a bug. When redisplay works on a window, current_buffer is bound to the buffer displayed by the window. See the call to set_buffer_internal_1 near the beginning of redisplay_window. > I guess an interesting part may be why clear_glyph_matrix failed. D= o > you think there is something interesting there? I just see normal operation of the display engine. The condition w->cursor.vpos < 0 means that try_window failed to find the cursor position after redisplaying the window, because point is not inside the window. IOW, try_scrolling tried to redisplay the window by reusing some of the results of the previous redisplay, but found that doing so would produce a window that does not include point. So it gives up. This is normal.