From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Idea: Be able to use text properties as face attributes Date: Tue, 28 Mar 2017 14:40:28 -0700 (PDT) Message-ID: <4f28c64b-400a-4902-8d8d-84bab71a7c2a@default> 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; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1490737268 21431 195.159.176.226 (28 Mar 2017 21:41:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2017 21:41:08 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 28 23:41:02 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 1csyrF-0003oO-Iu for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 23:40:53 +0200 Original-Received: from localhost ([::1]:55399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csyrJ-0006xL-PY for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 17:40:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csyr5-0006sr-9d for emacs-devel@gnu.org; Tue, 28 Mar 2017 17:40:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csyr0-0005K1-7P for emacs-devel@gnu.org; Tue, 28 Mar 2017 17:40:43 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29826) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1csyqz-0005JS-Tm for emacs-devel@gnu.org; Tue, 28 Mar 2017 17:40:38 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2SLea2n017336 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Mar 2017 21:40:36 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v2SLeYHS007644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 21:40:35 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v2SLeWm9025076; Tue, 28 Mar 2017 21:40:33 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 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:213467 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. >=20 > 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. Please reread what I wrote. I think there has been a misunderstanding. This feature has nothing to do with the display engine per se. It is only about leveraging a face's spec to manipulate other text properties at locations where the face is used. For that, we would extend face specs to tolerate (ignore) unknown face attributes (call them pseudo face attributes, if you like). And we would support one or more such attributes that are text-property symbols and their values. The code that does the supporting (interpreting) of such a (pseudo) face attribute-that-is-a-text-property is, it is clear by now (but it was not clear to me initially), typically _not_ in the display engine. I think we can remove "display engine" from the discussion. I'm sorry that I (naively) mentioned it when trying to make clear that _some C code_ would be implicated. Wherever that code is, it would check for the text property that it handles (1) first, by looking for a face property and checking for the text property as one of the face property's (pseudo) attributes, and (2) second, IF #1 did not yield the text property, looking for it directly on the text, as it does today. The only thing new would be #1: trying to get the text property first from a face property. That lets a face spec override text properties that might already be applied to the text directly, and it lets a face spec provide text props that are not yet applied (the general effect would be as if they had been applied directly). > 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. I can't speak to where or what code changes would be needed. I do think, however, that the behavior of `get-text-property' (and perhaps other functions) should _not_ be changed.=20 Instead we should add another function that gives Lisp code a way to do the checking described above: first, try to get the text property from within a face property, and then, if not obtained, use `get-text-property' to try to get it (directly) - as is the case now. > This said, I think using face attributes is a bad idea. Reason? I can be convinced, but only by reasons. > Instead, we should consider adding some more general system of > indirection. Drew suggests using `face` as a special meta-property. Yes, I suggest using `face', `font-lock-face', and `mouse-face' text properties to indirectly specify other text properties. I chose face properties not by accident, but because the feature would let you leverage both (1) existing face locations (occurrences), and (2) existing commands and other functions that let users and Lisp easily put a face property on text in various ways, or change it. Faces are special in those senses - they constitute especially handy affordances for manipulating text at locations that are common or significant for users. > 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). >=20 > 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. >=20 > From a more general point of view, the shared desire is to have > "abstract text properties" from which "actual text properties" > get computed. I'd be more interested in your proposal if I had a better idea of it. But I suspect that it might be independent of what I am getting at. It's true that I'm asking for a way to handle one or more text properties as a package at different locations. But my proposal is purposely aimed at FACES and where they are applied, for the reasons given above. It's not _only_ about packaging text props together to act on them in an abstract way. I fear I'm not getting the point across well, but I'm willing to keep trying if there is a real desire to understand. I fear that combining discussion of your proposal and mine in the same thread will not be helpful - unless it is a later thread, which can take advantage of conclusions already drawn about my proposal (e.g. yay or nay; specific challenges identified, whatever).