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:39:51 -0700 (PDT) Message-ID: <47dbc994-71ea-4606-9d9a-06bd7d800de4@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 1490737212 474 195.159.176.226 (28 Mar 2017 21:40:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2017 21:40:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 28 23:40:08 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 1csyqS-0007wN-WF for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 23:40:05 +0200 Original-Received: from localhost ([::1]:55390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csyqY-0006Qq-OS for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 17:40:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csyqP-0006OG-6n for emacs-devel@gnu.org; Tue, 28 Mar 2017 17:40:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csyqN-00052D-QZ for emacs-devel@gnu.org; Tue, 28 Mar 2017 17:40:01 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29546) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1csyqI-00050O-49; Tue, 28 Mar 2017 17:39:54 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2SLdq0E016647 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Mar 2017 21:39:52 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v2SLdqgP028011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Mar 2017 21:39:52 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v2SLdqvn014106; Tue, 28 Mar 2017 21:39:52 GMT In-Reply-To: <<83tw6d785i.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: userv0021.oracle.com [156.151.31.71] 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:213466 Archived-At: > > > As I explained, the display engine, which is the part that implements > > > the faces, will be unable to do anything with attributes that don't > > > affect display. > > > > Yes, you explained that. Thanks. > > > > Does that mean that such code could not invoke _other_ code > > that _would_ be able to do something with those text properties > > (that masquerade in a face spec as face attributes)? >=20 > We can invoke (almost) any code we like, but the question is what > would that other code do with those attributes? Those attributes, > like their corresponding text properties, have their effect when the > corresponding Emacs features are invoked, And that's the only time the face spec containing those properties needs to be handled by that other code. Instead of just looking for the text property that it handles, as something that belongs to the text char it checks, it would need to first check that char for a face property. And if there is a face property with that text property embedded in it (as a pseudo face attribute) then whatever that code would do with the text property it would do with the text property from the face spec. That's all. > like buffer text > modification for the 'read-only' property or keyboard > input processing for the 'keymap' property. Yes, exactly. The code that checks for and handles a `read-only' or a `keymap' text property would simply check for it in two places instead of one: (1) first, embedded in a face property, if there is one, (2) if not, directly on the char. > There's nothing we could do with these > attributes during processing of faces by the display engine, Yes, that's been clear for a while now. You were thrown off in that direction by my referring to "display engine" and "redisplay" out of ignorance of where in the C code this or that property is handled. The point is that _wherever_ a given text property is handled in the code, that code would need to take a larger view to check for the property. It would not look only for the property directly on the text; it would look also (and first) for that property as embedded in a face property (`face', `font-lock-face', or `mouse-face'). > Text properties are precisely a way to record such > information, but you don't want to use text properties in this case. I want to use a _face_ text property to record them. So yes, I do want to use a text property: one of the properties `face', `font-lock-face', and=20 `mouse-face'. And I want to (be able to) record the values of other text properties _within the value of the face property_. > So some other means of recording the information will > have to be invented. No. Not in my view. They would be recorded in a face property. No other recording needed. > But since those means will most probably be very similar to > text properties, at least implementation-wise, what would be the point > of inventing that? No such invention is needed, in my view. > > I think by now you should understand why I proposed the > > feature - its use. I've made that pretty clear. > > > > You are free to think that it's a useless feature, of course, > > and you are free to think that it might be useful but is not > > feasible to implement. >=20 > Sorry, I don't understand. My questions and my confusion are real, so > please bear with me and don't assume I'm repeatedly asking the same > questions for argument's sake. I'm asking them because I really don't > understand your motivation for proposing this feature in the form that > you proposed it. It's your proposal, so only you can explain its > details. OK, glad to hear that. Sometimes it's not clear. Do you understand now? If not, do you think there is something else I can add that would make things clearer? The motivation is to be able to leverage face-occurrence locations to manipulate (indirectly) text properties at those locations. We have functions - even user commands - that you can use to change the attributes of a face, and doing that affects all occurrences of the face (or all on a given frame, optionally). We can leverage these features to let users and code (in effect) manipulate other text properties at whole sets of locations at once. Which locations? Those of a given face. And we have umpteen ways to apply a face to different locations - again, either by Lisp or user commands. So users will be able to: 1. Put a face wherever they want (they can do that now). 2. Manipulate any text properties (that are supported) at those locations. Please let me know if this is becoming any clearer to you. Neither of us wants to waste the time of the other (and others), if there is no real communication going on.