From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Combining face and map stuff Date: Wed, 06 Oct 2010 01:43:03 +0200 Message-ID: References: <8739slfqg6.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1286322929 7526 80.91.229.12 (5 Oct 2010 23:55:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 5 Oct 2010 23:55:29 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 06 01:55:28 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 1P3HLz-00089L-D6 for ged-emacs-devel@m.gmane.org; Wed, 06 Oct 2010 01:55:27 +0200 Original-Received: from localhost ([127.0.0.1]:34164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P3HLy-0001Um-Cp for ged-emacs-devel@m.gmane.org; Tue, 05 Oct 2010 19:55:26 -0400 Original-Received: from [140.186.70.92] (port=44950 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P3HJn-0007uV-Hk for emacs-devel@gnu.org; Tue, 05 Oct 2010 19:53:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P3HA4-0006uq-FS for emacs-devel@gnu.org; Tue, 05 Oct 2010 19:43:09 -0400 Original-Received: from smtp2f.orange.fr ([80.12.242.150]:45596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P3HA2-0006sV-Ne; Tue, 05 Oct 2010 19:43:06 -0400 Original-Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2f02.orange.fr (SMTP Server) with ESMTP id D5D6F8000C18; Wed, 6 Oct 2010 01:43:05 +0200 (CEST) Original-Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2f02.orange.fr (SMTP Server) with ESMTP id C84258000E6D; Wed, 6 Oct 2010 01:43:05 +0200 (CEST) Original-Received: from fmsmemgm.homelinux.net (AMontsouris-552-1-131-244.w90-46.abo.wanadoo.fr [90.46.14.244]) by mwinf2f02.orange.fr (SMTP Server) with ESMTP id AA3F78000C18; Wed, 6 Oct 2010 01:43:05 +0200 (CEST) X-ME-UUID: 20101005234305697.AA3F78000C18@mwinf2f02.orange.fr Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 5CE39AE4B3; Wed, 6 Oct 2010 01:43:03 +0200 (CEST) In-Reply-To: <8739slfqg6.fsf@catnip.gol.com> (Miles Bader's message of "Tue, 05 Oct 2010 09:12:09 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-detected-operating-system: by eggs.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:131379 Archived-At: >>> 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. Of course, those conventions could be enforced via defadvices, I guess. But there's probably going to be some slightly subtle issues: when setting the `face' property, we can assume it's in the default nil plane, but reading the `face' property might mean "the `face' property in the nil plane" or "the merged `face' property". > Who knows, maybe it _could_ be implemented completely in lisp given > todays primitives ... but in order to make the layering thing work, > all the users would need to cooperate, presumably by means of > a wrapper layer. Right. Actually, that's why I like this idea: most of the work is done at a time when Elisp can be used, so you get a lot of flexibility, and you don't have to worry about interaction with tricky C code. E.g. maybe the merge function could be used to enforce priorities between planes, or to enable/disable planes (kind of like add-to-invisibility-spec). Stefan