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: Aborting display. Is this possible? Date: Mon, 20 Oct 2014 18:15:44 +0300 Message-ID: <831tq2db6n.fsf@gnu.org> References: <20141019141712.GB3197@acm.acm> <83lhoccdv7.fsf@gnu.org> <20141019154255.GC3197@acm.acm> <83egu4c4om.fsf@gnu.org> <20141020110949.GA2947@acm.acm> <877fzvrnb9.fsf@fencepost.gnu.org> <20141020120052.GC2947@acm.acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413818185 11040 80.91.229.3 (20 Oct 2014 15:16:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Oct 2014 15:16:25 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 20 17:16:18 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 1XgEgv-0005jB-5Z for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 17:16:13 +0200 Original-Received: from localhost ([::1]:45441 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgEgu-0005GP-Ir for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2014 11:16:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgEgq-0005G0-DI for emacs-devel@gnu.org; Mon, 20 Oct 2014 11:16:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgEgl-000359-75 for emacs-devel@gnu.org; Mon, 20 Oct 2014 11:16:08 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:34463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgEgb-00033u-WA; Mon, 20 Oct 2014 11:15:54 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NDR004000WTHQ00@mtaout28.012.net.il>; Mon, 20 Oct 2014 18:13:58 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDR001TJ0Z9RD20@mtaout28.012.net.il>; Mon, 20 Oct 2014 18:13:58 +0300 (IDT) In-reply-to: <20141020120052.GC2947@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.184 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:175591 Archived-At: > Date: Mon, 20 Oct 2014 12:00:52 +0000 > From: Alan Mackenzie > Cc: emacs-devel@gnu.org > > > > . Thus it seems either the command loop or CC Mode is fontifying _every_ > > > position which PageDown is scanning over. > > > > How couldn't it? Fontification affects how much material constitutes > > one page full of material. > > I suppose this is true in the fully general case, when different faces > on a GUI system can have different heights and widths. The display engine doesn't know when it is in the "non-general" case that allows it to make such shortcuts, except when the frame is a TTY frame. > Where in the source code, then, is this fontification being done as part > of a scrolling command? It's not part of a scrolling command, it is part of redisplay _after_ the scrolling command finishes. See my other message with the detailed description. > In the usual situation in a programming mode, however, characters are > going to be identical in size. There must be room for optimisation > somewhere. This is false, for several reasons. First, the display engine doesn't know anything about the semantics of the modes -- it doesn't understand how a programming mode is different from the other kind (and frankly, I'm not sure it is different, given the wealth of optional display features people tend to use in programming modes). Second, even if we would introduce a feature through which a major mode could tell the display engine that it is a "programming mode", you are wrong when you assume the characters are identical in size. Font-lock faces can legitimately be bold or slanted, in which case their size will be different. Emacs cannot know whether this is the case without examining the buffer positions it is about to display. I suppose we could add a feature whereby a mode or some other Lisp (e.g., some user-defined code) could tell the display engine that the buffer contents are "simple" in the sense that all the characters are of the same size, and then request the optional features that violate that to again tell the display engine. But we don't have that now, and never did.