From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Error during redisplay Date: Wed, 27 Feb 2008 09:34:11 +0100 Message-ID: <85ablmu7b0.fsf@lola.goethe.zz> References: <85ir0aubo1.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204101278 670 80.91.229.12 (27 Feb 2008 08:34:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Feb 2008 08:34:38 +0000 (UTC) Cc: lekktu@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 27 09:35:04 2008 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 1JUHkg-0002Xj-Pb for ged-emacs-devel@m.gmane.org; Wed, 27 Feb 2008 09:34:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUHkA-0000NY-Nw for ged-emacs-devel@m.gmane.org; Wed, 27 Feb 2008 03:34:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JUHk5-0000NJ-VA for emacs-devel@gnu.org; Wed, 27 Feb 2008 03:34:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JUHk3-0000N7-Ib for emacs-devel@gnu.org; Wed, 27 Feb 2008 03:34:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUHk3-0000N4-DY for emacs-devel@gnu.org; Wed, 27 Feb 2008 03:34:19 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JUHjy-0007B1-SR; Wed, 27 Feb 2008 03:34:15 -0500 Original-Received: from mail-in-13.arcor-online.net ([151.189.21.53]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JUHjy-0001Xz-2j; Wed, 27 Feb 2008 03:34:14 -0500 Original-Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id F00401E500F; Wed, 27 Feb 2008 09:34:12 +0100 (CET) Original-Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id BFFE56BD5F; Wed, 27 Feb 2008 09:34:12 +0100 (CET) Original-Received: from lola.goethe.zz (dslb-084-061-026-120.pools.arcor-ip.net [84.61.26.120]) by mail-in-14.arcor-online.net (Postfix) with ESMTP id 8E3D11874ED; Wed, 27 Feb 2008 09:34:12 +0100 (CET) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 494FA1C0027D; Wed, 27 Feb 2008 09:34:11 +0100 (CET) In-Reply-To: (Kenichi Handa's message of "Wed, 27 Feb 2008 17:04:14 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Virus-Scanned: ClamAV 0.92.1/6006/Wed Feb 27 02:03:40 2008 on mail-in-14.arcor-online.net X-Virus-Status: Clean X-detected-kernel: by mx20.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:90577 Archived-At: Kenichi Handa writes: > In article <85ir0aubo1.fsf@lola.goethe.zz>, David Kastrup writes: > >> Since the same string can be displayed with different fonts >> simultaneously, this would look like a fault in the design. The >> composition property/whatever apparently needs to be associated with >> the actual display, not just the string. > > In such a case, the composition property is generated each > time. The same situation happens when you display the same > portion of a buffer in two frames with different fonts. > > It may result in a little bit slower redisplay. If such a > situation happens often and the slowness is so painful, > perhaps the composition property must be an alist of fonts > vs the current value. It's not that difficult to implement. I still think it wrong to change the text according to where it is displayed. This would appear to call at most for overlays (which can be window specific and where changing them does not change the underlying text). So this sort of information probably belongs in the glyph matrix or whatever it is called. As far as I know, text properties are also subject to undo treatment. It just makes me queasy to think about this. > So, another way is to re-design the current redisplay engine > to generate a composition glyph every time just by calling C > functions. I think it's an interesting experiment. Sounds more like "sane" than "an interesting experiment" to me. But on the other hand, I have no relevant experience or knowledge whatsoever. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum