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: Combining face and map stuff Date: Wed, 06 Oct 2010 05:57:59 +0200 Message-ID: <83y6acnfaw.fsf@gnu.org> References: <8739slfqg6.fsf@catnip.gol.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1286337482 16420 80.91.229.12 (6 Oct 2010 03:58:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 6 Oct 2010 03:58:02 +0000 (UTC) Cc: emacs-devel@gnu.org, miles@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 06 05:58:01 2010 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.69) (envelope-from ) id 1P3L8i-0000yE-Kt for ged-emacs-devel@m.gmane.org; Wed, 06 Oct 2010 05:58:00 +0200 Original-Received: from localhost ([127.0.0.1]:53811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P3L8i-0002Fx-1z for ged-emacs-devel@m.gmane.org; Tue, 05 Oct 2010 23:58:00 -0400 Original-Received: from [140.186.70.92] (port=52193 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P3L8c-0002D8-9N for emacs-devel@gnu.org; Tue, 05 Oct 2010 23:57:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P3L8Z-0002Ig-Ov for emacs-devel@gnu.org; Tue, 05 Oct 2010 23:57:54 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:52016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P3L8Z-0002IO-El; Tue, 05 Oct 2010 23:57:51 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L9U00K00O3L0C00@a-mtaout21.012.net.il>; Wed, 06 Oct 2010 05:57:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.135.76]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L9U00J3UOCCVW70@a-mtaout21.012.net.il>; Wed, 06 Oct 2010 05:57:49 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:131385 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , emacs-devel@gnu.org > Date: Wed, 06 Oct 2010 01:43:03 +0200 > > >>> It sounds like he's saying it would use their union, with a > >>> property-specific function used to compute that union. > >>> [and that the union computation could be done at "property setting time" > >>> rather than at display time, to avoid speed problems.] > >> I'm probably missing something here: if the union is computed at > >> put-text-property time, then how is this different from what we have > >> now? That union will have all the properties of the character lumped > >> together, just like what we have now, right? What am I missing? > > You're missing that in order o properly update the merge when some > property is added/removed in a plane, all users of text properties will > have to follow some new conventions. When I said "what am I missing", I meant the advantages of what you propose. Having to follow some new conventions sounds like the price one has to pay for having these advantages, but what are the advantages themselves? If the new protocol itself is the advantage, then perhaps what I'm missing is the essence of the problems that you proposal is trying to solve.