From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: grischka Newsgroups: gmane.emacs.devel Subject: Re: redisplay - very long lines Date: Wed, 18 Feb 2009 21:41:32 +0100 Message-ID: <499C727C.50104@gmx.de> References: "ueixyw5bh.fsf@gnu.org" <499AF0DA.7050306@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1234989779 573 80.91.229.12 (18 Feb 2009 20:42:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Feb 2009 20:42:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 18 21:44:15 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 1LZtGx-00020O-2v for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2009 21:43:59 +0100 Original-Received: from localhost ([127.0.0.1]:32875 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZtFd-00018y-1I for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2009 15:42:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZtFY-00018j-Ou for emacs-devel@gnu.org; Wed, 18 Feb 2009 15:42:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZtFY-00018X-3q for emacs-devel@gnu.org; Wed, 18 Feb 2009 15:42:32 -0500 Original-Received: from [199.232.76.173] (port=34982 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZtFX-00018U-Vz for emacs-devel@gnu.org; Wed, 18 Feb 2009 15:42:32 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]:53354) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LZtFX-0001oy-8O for emacs-devel@gnu.org; Wed, 18 Feb 2009 15:42:31 -0500 Original-Received: (qmail invoked by alias); 18 Feb 2009 20:42:25 -0000 Original-Received: from p57A082C4.dip0.t-ipconnect.de (EHLO [192.168.1.5]) [87.160.130.196] by mail.gmx.net (mp070) with SMTP; 18 Feb 2009 21:42:25 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX19IH0AHBDtIF8AB6vCjrxGCdBWo2gkae/Cu0EGqZP oTzruVna5qmEly User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:109199 Archived-At: Eli Zaretskii wrote: >> 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. The buffer text itself is not the only data to control the display, there are also properties that refer to regions of that text, and in fact that is the part that matters here. It is certainly possible to check for at least the presence of extra properties in a line without walking each character one by one. > > 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. >