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: Thu, 17 Jun 2010 21:10:55 +0200 Message-ID: References: <87ocfcj7r4.fsf@mail.jurta.org> <87631jvpzg.fsf@gmail.com> <4C18211C.3070106@harpegolden.net> <83typ2isns.fsf@gnu.org> <83mxuuicjc.fsf@gnu.org> <83ljadikj1.fsf@gnu.org> <83k4pxijpb.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 1276801891 27127 80.91.229.12 (17 Jun 2010 19:11:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Jun 2010 19:11:31 +0000 (UTC) Cc: david@harpegolden.net, emacs-devel@gnu.org To: Eli Zaretskii , "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 17 21:11:27 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 1OPKUo-0002DZ-Sb for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 21:11:27 +0200 Original-Received: from localhost ([127.0.0.1]:55133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPKUn-0002nj-VR for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 15:11:25 -0400 Original-Received: from [140.186.70.92] (port=54821 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPKUg-0002jr-3I for emacs-devel@gnu.org; Thu, 17 Jun 2010 15:11:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPKUe-00052q-ON for emacs-devel@gnu.org; Thu, 17 Jun 2010 15:11:17 -0400 Original-Received: from mail-gx0-f169.google.com ([209.85.161.169]:64833) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPKUe-00052k-JM; Thu, 17 Jun 2010 15:11:16 -0400 Original-Received: by gxk3 with SMTP id 3so204309gxk.0 for ; Thu, 17 Jun 2010 12:11:16 -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=PM8xKxfKIFD9WHEbvDLbjdEUTjjDaR5AJNnwtIYlq/0=; b=QV/2w5TJifrjokYRhtR6+ONbxg6jzaU+CqmIcSHOA0a4idczuYexv7BheLQKn8dGOc 2yhCHIQlKojZ3oMViflPqn2eIDOUl1M2n4Li4MXVKYTO9yoiOpaBdlejFMKa/U4z0Y27 Aqn0cHwaKfDwLwYagJrzAabBh8faQZtyUdDYA= 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=kqvdfQDYrzb1R1ylZAN+GK5U67hG3OA6PcNWSlvbAEDZM62glAqx9rjcxNcNr/pO8q vOvT6ApM8GnGk7uSTiduVrFmcEykDyuxpBeTImOacT+yqstmHec5AyDqHhVWtXVl+oYN 0A9n2uJ7BFuUdZ4EbW4g820CawqQMrZ7xlu/8= Original-Received: by 10.101.5.31 with SMTP id h31mr9119274ani.158.1276801875837; Thu, 17 Jun 2010 12:11:15 -0700 (PDT) Original-Received: by 10.100.154.15 with HTTP; Thu, 17 Jun 2010 12:10:55 -0700 (PDT) In-Reply-To: <83k4pxijpb.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:126087 Archived-At: On Thu, Jun 17, 2010 at 8:43 PM, Eli Zaretskii wrote: >> From: Lennart Borgman >> Date: Thu, 17 Jun 2010 20:32:27 +0200 >> Cc: emacs-devel@gnu.org, david@harpegolden.net >> >> Several of us has said that the problem is easily reproduceable. > > Please show a recipe starting from "emacs -Q". I am sorry, I thought that was clear. Just open a large C file for example, like window.c. Set the variables as suggested earlier in this thread that should prevent "jumping scrolling". Then just hold down or rapidly press the down arrow. You will see (if your pc is not too fast) that Emacs does the "jumping scrolling" now and then. Not every time, but now and then, probably when it gets behind in screen updating. >> The conclusions are based on the logic of the source code. But you >> seem to think they are unwarranted. Can you please explain what part >> of the patches you think are unwarranted or unexplained? > > I cannot explain anything yet, because I cannot follow your reasoning > and thus cannot assess the changes you suggest. =C2=A0That's why I asked > the questions you didn't answer. Hi Eli, I will try to explain, but a problem for me is that I do not know where to start when explaining. You did not comment on the explanation I gave with the patches. So I just do it the best I can. Please just tell me what you do not understand. I said that clip_changed is used only by the display routines. Only those routines knows exactly what data was used when redisplay was done. Clipping is part of the data that might influence redisplay. Changing clipping might invalidate what is displayed or it may not. In the current code (without my patch) there is a very rough guess about this: "if clipping is change we should invalidate the display of every window". So this is what `narrow-to-region' and `widen' did by setting clip_changed = to 1. I removed that guess and made another, a little bit less rough guess: "if clipping is not the same as when last redisplay was done we should invalidate the display". This is (nearly) on the safe side. It invalidate the display even if the changes in clipping actually does not need to invalidate the display. If something above is unclear then please ask. I now have questions to you. As you can see above there are two a bit weak points in the last paragraph of my explanation. The last part is a bit more easy so I start with that. Is there an easy way to find out if the change in the clipping data did not invalidate the display? That could be great. Now to the more problematic part. This patch is not yet finished because there is one thing that I have forgotten to fix after testing: I have implemented this in redisplay_window, i.e. the cashing of the clipping should have been per window, but it is per buffer at the moment. I guess that this is quite easy to fix by moving the cashing of the clipping data to the window instead. However when I came to think about this I wondered if the display of a buffer in several windows is in some (magic) way connected. I don't think they are, but anyway I ask you: are they?