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: Unfreezing the display during auto-repeated scrolling. [ Was: Aborting display. Is this possible? ] Date: Sun, 26 Oct 2014 22:20:46 +0200 Message-ID: <83a94i4m75.fsf@gnu.org> References: <83lhoabl2x.fsf@gnu.org> <20141020210819.GE2947@acm.acm> <87y4s9rgi9.fsf@fencepost.gnu.org> <83zjcpa11g.fsf@gnu.org> <20141021171403.GB3035@acm.acm> <83oat59ucc.fsf@gnu.org> <20141021183807.GD3035@acm.acm> <20141026124333.GA4397@acm.acm> <83h9yq4w5g.fsf@gnu.org> <20141026200313.GE4397@acm.acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1414354890 23590 80.91.229.3 (26 Oct 2014 20:21:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Oct 2014 20:21:30 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 26 21:21:23 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XiUJV-0001O4-Am for ged-emacs-devel@m.gmane.org; Sun, 26 Oct 2014 21:21:21 +0100 Original-Received: from localhost ([::1]:58305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiUJU-0005F7-Np for ged-emacs-devel@m.gmane.org; Sun, 26 Oct 2014 16:21:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiUJE-00058g-Lc for emacs-devel@gnu.org; Sun, 26 Oct 2014 16:21:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiUJ9-0002C5-TG for emacs-devel@gnu.org; Sun, 26 Oct 2014 16:21:04 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:32967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiUJ9-0002Br-FK for emacs-devel@gnu.org; Sun, 26 Oct 2014 16:20:59 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NE200000IEYLS00@mtaout25.012.net.il> for emacs-devel@gnu.org; Sun, 26 Oct 2014 22:16:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE200MX7IZAME40@mtaout25.012.net.il>; Sun, 26 Oct 2014 22:16:22 +0200 (IST) In-reply-to: <20141026200313.GE4397@acm.acm> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175875 Archived-At: > Date: Sun, 26 Oct 2014 20:03:13 +0000 > Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > From: Alan Mackenzie > > > You cannot possibly know, on this low level, which code will use the > > "not for display" functions, even if today they are only used in a > > context where ignoring font-lock faces might be OK. > > The contract of xdisp.c says explicitly that the only visible display > function is redisplay, and this has no IT parameters. So any IT with > not_for_display set should be "safe" if it is defined outside of xdisp.c No, that's wrong, because subroutines of redisplay_internal call the "not-for-display" functions in many places, and they certainly do NOT expect that those function behave differently, in terms of pixel metrics and coordinates, from the "real" display. E.g., if a series of move_it_* calls with a certain goal winds up at some pixel coordinates within the current window, the code expects to find itself at the same place when it actually displays the text. If this condition is violated (because move_it_* functions ignore font-lock faces), then all kinds of subtle breakage will ensue. > > You already marked as "not for display" line-pixel-height, which must > > be accurate in the results it returns, since otherwise it will violate > > its contract. Likewise in resize_mini_window (which is definitely "for > > display"), redisplay_internal (likewise), etc. OTOH, displaying > > strings (e.g., as part of mode-line display) will never bump into > > font-lock faces, so setting this flag there is not useful. > > Sorry, I'd left unnecessary not_for_display's set. I've cleared out > xdisp.c, such that the only function which sets not_for_display is > pos_visible_p. That's also wrong: that function is a base for many APIs, specifically the posn-at-* functions, that many features use and depend on. You cannot violate their accuracy. > The other functions which set not_for_display are > (i) window_scroll_pixel_based (window.c); > (ii) Fvertical_motion (indent.c). Fvertical_motion is called in many places. Martin worked very hard to make window and frame redisplay be accurate to a single pixel; you are now going to ruin all that. > > So if we go this way, we are digging a hole for ourselves -- it is an > > impossible maintenance burden to have functions that don't exactly do > > what they say they do under some circumstances. > > Yes. But the current implementation doesn't work very well. I'm trying > to fix it, because it's irritating. I think I've made good progress. I > can't see any other approach to fixing it at the moment. I do, at least two of them, and I pointed them out. In any case, if there's no good solution for a problem, it certainly doesn't mean we should compromise with a not-so-good one. > > You should only make changes in window_scroll_* functions, ... > > I honestly can't see how I could achieve what's wanted if I restrict > myself to window.c. Please tell what prevents you from doing that. > > And I still don't understand why writing a simple "fast-scroll" > > function in Lisp, which just moves point N lines forward or backward, > > is not a better solution. It's certainly easier and has exactly zero > > impact on our infrastructure. > > That's precisely how Fscroll_up and Fscroll_down work. No, they don't. If they did, you wouldn't need to disable fontification, because moving point doesn't need it. What Fscroll_down and Fscroll_up do is move the _window_start_, and then figure out whether point is still visible after that. When you move point first, all this is not needed, especially if you don't care that point will move slightly less or more than a screenful.