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: redisplay - very long lines Date: Tue, 17 Feb 2009 21:37:10 +0200 Message-ID: References: "ueixyw5bh.fsf@gnu.org" <499AF0DA.7050306@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1234899476 1788 80.91.229.12 (17 Feb 2009 19:37:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Feb 2009 19:37:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 17 20:39:11 2009 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.50) id 1LZVmC-0007Xn-Ha for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2009 20:38:40 +0100 Original-Received: from localhost ([127.0.0.1]:58058 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZVks-0000Nw-AY for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2009 14:37:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZVko-0000Np-HY for emacs-devel@gnu.org; Tue, 17 Feb 2009 14:37:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZVkn-0000Nd-F2 for emacs-devel@gnu.org; Tue, 17 Feb 2009 14:37:14 -0500 Original-Received: from [199.232.76.173] (port=44574 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZVkn-0000Na-9C for emacs-devel@gnu.org; Tue, 17 Feb 2009 14:37:13 -0500 Original-Received: from mtaout6.012.net.il ([84.95.2.16]:31257) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZVkm-0006um-QO for emacs-devel@gnu.org; Tue, 17 Feb 2009 14:37:13 -0500 Original-Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KF80090066SXS00@i-mtaout6.012.net.il> for emacs-devel@gnu.org; Tue, 17 Feb 2009 21:37:42 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.228.82.14]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KF800CKS6ITFA00@i-mtaout6.012.net.il>; Tue, 17 Feb 2009 21:37:42 +0200 (IST) In-reply-to: <499AF0DA.7050306@gmx.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) 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:109141 Archived-At: > Date: Tue, 17 Feb 2009 18:16:10 +0100 > From: grischka > CC: emacs-devel@gnu.org > > > If we can tolerate an incorrect display, maybe. The invisible part of > > the line could in principle include characters and faces whose > > presence may have global effects on the rest of the displayed portion, > > such as faces that use larger fonts, to say nothing of inline images. > > That is not a necessary consequence at all. > > After all faces and images don't come fallen from outer space into > the text but if they exist then it was the emacs program itself that > has put them there. So instead of scanning lines each time it could > as well just remember where and how big they are. AFAIU, you are talking about a complete redesign and rewrite not only of the Emacs display engine, but also of one of the most important parts of its top-level design, because in the current design code that modifies buffers and code that displays them are almost completely decoupled, i.e. there's almost no control flow between them, and the only data flow is thru the buffer text itself. IOW, under the current design, Lisp application code modifies buffers, and then, when Emacs is idle, redisplay kicks in, walks the buffers, decides which parts need to be redisplayed (by comparing the current and the new display contents), and finally redraws those parts. This way, the code that works with buffer text knows (almost) nothing about display, and the code that displays knows (almost) nothing about editing.