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: Mon, 27 Mar 2017 09:22:23 -0700 (PDT) Message-ID: <8080a162-700f-42cc-aec9-5fdd7c646297@default> References: <<7a902f7b-d808-4d0f-8ff9-b8f07eaddf83@default>> <<83h92e93ip.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 1490631826 14320 195.159.176.226 (27 Mar 2017 16:23:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Mar 2017 16:23:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 27 18:23:41 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 1csXQd-0002aJ-4D for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 18:23:35 +0200 Original-Received: from localhost ([::1]:47964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csXQj-0003OP-3X for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 12:23:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csXPg-0003LG-0f for emacs-devel@gnu.org; Mon, 27 Mar 2017 12:22:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csXPe-00022L-7E for emacs-devel@gnu.org; Mon, 27 Mar 2017 12:22:36 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51705) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1csXPY-0001oC-6s; Mon, 27 Mar 2017 12:22:28 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2RGMQ6a017366 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Mar 2017 16:22:26 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v2RGMPlY009473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Mar 2017 16:22:25 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v2RGMPYb028787; Mon, 27 Mar 2017 16:22:25 GMT In-Reply-To: <<83h92e93ip.fsf@gnu.org>> 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: aserv0021.oracle.com [141.146.126.233] 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:213423 Archived-At: > > The idea is to allow the use of text properties as > > attributes for the text (and overlay) properties `face', > > `font-lock-face', and `mouse-face'. This would apply to > > faces used in strings (e.g., `propertize') as well as in > > buffers. > > > > It would let you, for example, use a property such as > > `invisible', `keymap', or `read-only' (even `display'?) as > > part of a face definition. > > > > Any properties that either cannot be implemented or do not > > make sense for faces would be excluded (i.e., ignored). But > > I'm guessing that most could be accommodated. > > > > Setting such a face attribute would have the effect that all > > occurrences of text with that face, when redisplayed, would > > appear as if the text property were applied directly to the > > text that has that face. > > > > For example, this would make all doc strings invisible: > > > > (set-face-attribute 'font-lock-doc-face nil 'invisible t) >=20 > Some comments/questions about this: >=20 > First, I don't understand why you want to "burden" faces and the > display engine with this job. It sounds like the job has nothing to > do with faces per se, and that faces were chosen simply because > font-lock is automatically applied by redisplay. Is that right? No. It has nothing particular to do with font-lock. As I said, it is about (having the effect of) changing the text properties at all occurrences of a given face, all at once (modulo redisplay time) > If so, I think we should consider alternative, more straightforward > approaches. For example, if what you are looking for is a way to put > a specific text property on any text with a particular FACE, The "if so" part is wrong - see above. And this is not about actually putting a text property on the text. This is about getting that effect without doing that. The actual text properties on the relevant text would be those that it had before, with the exception that its `face' property would have (pseudo face) attributes that correspond to non-face text properties. The latter would be taken into account by the display engine, to give the effect of their having been put on the text directly. The indirection allows confining this behavior to the face occurrences and removing it from only the face occurrences. > I think > you can write a function to do that by searching for face property > changes and adding that property to each stretch of text with that > FACE. See above. It is not about having a convenient way to directly alter the text properties of the subject text. It is about getting that effect without altering them. It is about associating that effect with the particular face (only). > Such a function can be written in Lisp, and doesn't require any > infrastructure changes. Would such a function do the job you had in > mind? We could make it part of Emacs, so people won't need to > reinvent it each time. No; please see above. I'm not looking for a way to add text properties wherever a given face property is present. I'm looking for a way to encapsulate a set of text properties with a face, so they effect the display of text that has that face, but they are not directly applied to the text. They are tied to presence of the face, and they can be changed or removed by changing the face spec. It's just about using the face as a "carrier" of text properties. > Using the display engine for this job is also problematic in several > other aspects: >=20 > . It will slow down redisplay, because the display code will now have > to examine faces where it previously didn't. For example, for > implementing invisible text: the current code looks just at the > invisible properties of text and overlays; under your suggestion it > will also have to look for faces. Correct. And more generally, it would affect tests for a text property. As mentioned in my previous mail, I don't think that the current functions (`get-text-property', `next-single-property-change, etc.) that test for text properties should be changed. Instead, we would add parallel functions that test for text properties not just being directly present but also being "present" by implication, i.e., indirectly, i.e., by way of a face property. I can't speak to the implementation (display engine etc.). I'm glad that you are at least open to thinking about this, since you are our expert on the display engine. If the idea is totally unfeasible or unrealistic, you would likely be the one to speak to that. If it affects performance significantly to also test for a face property and check its attributes for a text property then perhaps that extra check could be controlled by a global variable. IOW, if code needs this feature then it can "turn it on", and otherwise the display engine would act as it has in the past. > . Most text properties we support don't affect the display of text: > consider 'keymap' or 'read-only' or 'intangible' or > 'modification-hooks', to name just a few. Yes. I addressed such properties specifically. I don't know where in the base code they are handled, so I spoke only of "display engine". But from a user point of view they would be handled the same way in this suggestion. The property would not be added to the text, but rather it would stay as an attribute of the `face' (or `font-lock-face' or `mouse-face') property. It would have the _effect_ of having been added to the text. E.g., the text with the particular face would behave as if it had the given `keymap' property value. And yes, most Lisp code that tests text for such a property would likely use a different function to test/obtain it. For example, it would use `get-text-property-implied' (new), which would check first for a face property that has the given property as an attribute. If present, that would be returned; if absent then the `get-text-property' result would be returned. We could also, say, have `get-text-property-implied' distinguish, in its result, whether the property was directly present or was implied by virtue of being part of a face spec. One way to do that might be to put the return value in parens for one of the cases. For example, if implied, the return value could be a cons (FACE . VALUE), where FACE is the face and VALUE is the value of the text property in its face spec. (Maybe a slightly different convention should be used, as that's not foolproof. A text property that is directly present could have a value of a cons whose car is a face.) > And of course, > applications can invent any properties they like. I addressed that too. > How do you > expect the display engine to make your face attributes "appear as > if the corresponding text property was applied" to the text, if the > corresponding text properties don't affect the text appearance on > display? The display engine doesn't apply any properties, it > produces glyphs for displaying text. I said this: And let's not forget that anyone can create any text property (e.g. `jkjkljkl'), with any value, and apply it to some text. Some text properties that are not really related to faces are built-in (`emacs -Q'). Others are created by user code that alone determines how they behave - what their effect is. A user-defined text property is unknown to `emacs -Q'. It is up to the code that defines it to do what it wants with it, including (if it wants) any indirect use of it as a face attribute. IOW, not Emac's problem. User code will typically not expect or need any such feature, and if it does then it will need to take care of that itself. > In addition, text property search will also become slower, for the > same reason redisplay will become slower, as explained above. Yes; see above, where I mention `next-single-property-change' as one example. > > Face merging is already well defined, in particular for > > cases where there is a conflict between the values of the > > same attribute, so I don't expect any problem there. >=20 > Not sure if this is relevant, but if it is, then the existing face > merging won't help us, because it is only defined for visual > attributes, not for the additional ones you want to define. Either we could decide that that is acceptable, in which case there would never be a conflict for such "attributes" (e.g., the "latest" face spec applied would win, wrt their effect - or only the first face spec would win), or we could enhance the face-merging code to treat any unknown face "attributes" similarly: have Emacs "apply" them as if that were the only face. > > One open question would be whether to allow the text > > properties `face', `font-lock-face', and `mouse-face' as > > properties for themselves and each other. E.g., be able > > to do this: > > (set-face-attribute 'face-1 nil 'face 'face-2) > > or this: > > (set-face-attribute 'face-1 nil 'font-lock-face 'face-1) > > > > These properties could be excluded (ignored), but allowing > > them might prove useful. It would provide a simple way to > > (e.g. temporarily) substitute one face for another >=20 > How is this different from overriding attributes of a face by those of > another face, something I believe you can do today? Not sure what you have in mind. The above would have the _effect_ of showing all occurrences of `face-1' as if they were occurrences of `face-2', or (in the second example) of handling them as if they were occurrences of `font-lock-face'.