From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: The unwarranted scrolling assumption Date: Fri, 18 Jun 2010 15:45:18 +0200 Message-ID: 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> <838w6cixma.fsf@gnu.org> 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 1276868781 4830 80.91.229.12 (18 Jun 2010 13:46:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 18 Jun 2010 13:46:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 18 15:46:17 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 1OPbtc-0005VH-Cq for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 15:46:16 +0200 Original-Received: from localhost ([127.0.0.1]:39370 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPbtY-0007nx-Eh for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 09:46:08 -0400 Original-Received: from [140.186.70.92] (port=55241 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPbtH-0007fV-5Q for emacs-devel@gnu.org; Fri, 18 Jun 2010 09:45:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPbt6-0002e0-F4 for emacs-devel@gnu.org; Fri, 18 Jun 2010 09:45:45 -0400 Original-Received: from mail-gy0-f169.google.com ([209.85.160.169]:59685) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPbt6-0002dv-Bf; Fri, 18 Jun 2010 09:45:40 -0400 Original-Received: by gyg4 with SMTP id 4so974104gyg.0 for ; Fri, 18 Jun 2010 06:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=dW012fcrDyf7MtNgwA5Ot1FcZTqLfuASjDyiHV26XR8=; b=KSveI/lmmtIl+zh+r7irqyzW3DgxnPYCJnCTgsumqn2FNwdXlWjz2Ho8DSk/IgTkUu a10kACWuXNQdBF0pdwpGiXJLPr+fLrPCJWncg1E3hpBJKzEXW0Vyv2OEn97qzMXYG2q6 wAfrn7GpUcSa6pF+tJYkDfX6mSPfUc9sIVMCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=mhwWJ8I2RZqKLm7hXvhm3gF6TcHXDOJlIJU07RcqTzt2a230WxmXcPfJaN397ZRM7H mZ7GJRJhAmhIYHhx2Z+vmL08I8NxrHY1ggDn50bpL2xv0Mvtc4wh0uPcxIMChifTO1zw CjGjKVrAwP+gyVB1ZLx5QH8lQhN8kBRk3Mnhk= Original-Received: by 10.100.193.15 with SMTP id q15mr902871anf.152.1276868739310; Fri, 18 Jun 2010 06:45:39 -0700 (PDT) Original-Received: by 10.100.154.15 with HTTP; Fri, 18 Jun 2010 06:45:18 -0700 (PDT) In-Reply-To: <838w6cixma.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:126153 Archived-At: On Fri, Jun 18, 2010 at 9:54 AM, Eli Zaretskii wrote: >> From: Lennart Borgman >> Date: Fri, 18 Jun 2010 00:16:33 +0200 >> Cc: emacs-devel@gnu.org >> >> > Again, PLEASE answer my questions, if you really want my help in >> > understanding this issue. =C2=A0What parts of the above condition prev= ented >> > reconsider_clip_changes from resetting b->clip_changed to zero? =C2=A0= If >> > needed, please re-run under GDB (without your patches) and see what >> > other factors are at work here. >> >> 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 think >> 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 supposed > to fix it. Yes and no. If you look at my other messages you can see there are two distinct bugs that I have seen that leads to the "jumping scrolling" (the problem with clip_changed and the bug regarding visual-line-mode). To clear things out I think it would be good if you (and anyone interested) looked at the patch I have sent first. I have tried to explain why I did this patch so please reread my messages first if something is unclear. > Emacs uses the recenter as the last resort, and it does this in many > different situations. =C2=A0Discovering another situation where it happen= s > does not help to understand the one you discovered before, and the > patch to correct it (assuming we want that) might be entirely > different. =C2=A0This just adds confusion. I can see that this is confusing if still find my patch unclear. So at least now it is clear that I think there are two distinct bugs that leads to "jumping scrolling" (which I think is a better description than "recentering"). >> 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 there >> is one problem though it has not shown up). >> - It is quite hard to make Emacs do the "jumping scrolling". >> >> So it is better, still there are problems. > > It may be "better" in the use-cases you tried. =C2=A0But without > understanding the original problem and why your patch fixes it, it is > quite likely that the patch will introduce other redisplay problems. So you think that the patch may introduce redisplay problems? That concern is good, but can you seen something in the patch that you think will cause problems? Maybe it helps if I explain that the patch is not about how the screen is updated. It is only about when it is updated. At least that was my intention. > try_scrolling may legitimately fail in some cases. Maybe, but I do not think that is the problem here. >> BTW, the use of current_buffer here seems to me to be a bug. > > No, it isn't a bug. =C2=A0When redisplay works on a window, current_buffe= r > is bound to the buffer displayed by the window. =C2=A0See the call to > set_buffer_internal_1 near the beginning of redisplay_window. Thanks. I missed that. Then it is just a matter of style. I really think that using current_buffer there is not the best. >> I guess an interesting part may be why clear_glyph_matrix failed. Do >> you think there is something interesting there? > > I just see normal operation of the display engine. =C2=A0The condition > > =C2=A0w->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. =C2=A0So it gives up. =C2= =A0This > is normal. Thanks, that is good to know, but I think there is a bug in this case. Can you please reread the message where I talked about how to reproduce this around line 702 in window.c?