From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Idea: Be able to use text properties as face attributes Date: Tue, 28 Mar 2017 11:26:59 -0400 Message-ID: References: <7a902f7b-d808-4d0f-8ff9-b8f07eaddf83@default> <30d920b0-e1de-497d-98de-8b69e835e855@default>>> <30eb5a49-2d98-4f37-8f8c-32a88cd76827@default>>> <83bmsm938f.fsf@gnu.org>>> <7f98847c-9b5e-47cf-85f2-247c2045d0af@default>> <834lye8s1k.fsf@gnu.org>> <93aa220a-35c8-4be1-bfb5-299c46c9eba9@default> <83tw6d785i.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1490714869 20357 195.159.176.226 (28 Mar 2017 15:27:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2017 15:27:49 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 28 17:27:45 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cst1u-0003eX-PZ for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 17:27:30 +0200 Original-Received: from localhost ([::1]:53923 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cst20-0006yV-PX for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 11:27:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cst1v-0006yQ-7m for emacs-devel@gnu.org; Tue, 28 Mar 2017 11:27:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cst1r-0006lP-3R for emacs-devel@gnu.org; Tue, 28 Mar 2017 11:27:31 -0400 Original-Received: from [195.159.176.226] (port=35485 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cst1q-0006lD-TP for emacs-devel@gnu.org; Tue, 28 Mar 2017 11:27:27 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cst1Y-0001ZY-IV for emacs-devel@gnu.org; Tue, 28 Mar 2017 17:27:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:+U/oMfgi344XmdME+JkbK05m6eQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:213455 Archived-At: > for the 'keymap' property. There's nothing we could do with these > attributes during processing of faces by the display engine, except > record those attributes somewhere, for future use by their respective > features. It's worse: the rest of the code can't assume that the display rendering has propagated the info from the fact attributes to that "to-be-defined-other-place" since redisplay may not have happened yet or may not have looked at that part of the buffer yet. This said, Drew's feature doesn't have to require changes all over the place. It might be possible to limit those changes to a few core place like Fget_text_property. This said, I think using face attributes is a bad idea. Instead, we should consider adding some more general system of indirection. Drew suggests using `face` as a special meta-property. Current code already supports such a feature but using the name `category` and only for overlays (and with some problems linked to the fact that modifying that meta-property is done via `get` and `put` which are very generic operations used for many other things, so it's hard/impossible to detect when those meta-properties are changed, which is a fairly serious problem. The only reason why we don't suffer too much from that problem is because those `category` properties aren't used very often). My proposal for "property planes" is somewhat related to Drew's proposal: my "property planes" allow merging various properties into one (font-lock can place the (font-lock face) property, and some other package can add the (mypkg face) property and they then get merged into the one-and-only `face` property), i.e. many-to-one. Drew wants the reverse: adding a single meta-property which then affects several other properties, i.e. one-to-many. >From a more general point of view, the shared desire is to have "abstract text properties" from which "actual text properties" get computed. Stefan