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 13:01:38 -0700 (PDT) Message-ID: <19e94d18-656f-4a8f-8843-4d46ffdd037b@default> References: <<<7a902f7b-d808-4d0f-8ff9-b8f07eaddf83@default>>> <<<83h92e93ip.fsf@gnu.org>>> <<8080a162-700f-42cc-aec9-5fdd7c646297@default>> <<8360iu8sdm.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 1490644929 29734 195.159.176.226 (27 Mar 2017 20:02:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Mar 2017 20:02:09 +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 22:02: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 1csaps-0006Cg-4p for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 22:01:52 +0200 Original-Received: from localhost ([::1]:48736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csapx-0001sm-Vf for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 16:01:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csapo-0001rQ-RD for emacs-devel@gnu.org; Mon, 27 Mar 2017 16:01:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csapn-00072o-9v for emacs-devel@gnu.org; Mon, 27 Mar 2017 16:01:48 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:26267) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1csapj-0006xb-ET; Mon, 27 Mar 2017 16:01:43 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2RK1gtF025593 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Mar 2017 20:01:42 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v2RK1fU9030533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Mar 2017 20:01:42 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v2RK1d6I003710; Mon, 27 Mar 2017 20:01:40 GMT In-Reply-To: <<8360iu8sdm.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: 141.146.126.69 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:213432 Archived-At: > > > 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) >=20 > But you explicitly mention "redisplay" above, and the display engine > doesn't care about any properties unrelated to font-lock or faces. So > now I'm even more confused about the proposal. Modulo "update" time, if you prefer. (And this was mentioned in paretheses, in hopes that it might help understanding. You can ignore it if it does not help you.) I have no idea where in the Emacs code particular text properties are handled. Some code, somewhere, takes care of implementing their effects. I don't know what triggers different kinds of such updates, so I spoke in a general way about "redisplay". Substitute whatever wording you prefer, to indicate that there might be (I don't know) some delay between (1) changing the face property and (2) realizing the effect of doing so. > > And this is not about actually putting a text property on the text. > > This is about getting that effect without doing that. >=20 > What for? You provided no rationale for having such "virtual" > properties. The only rationale you provided is that of a convenience > feature which would allow to quickly and simply make specific portions > of text behave as if they have those properties. I'm asking why not > actually give them those properties. What does it gain us? I did speak to that - several times now. The point is to associate the effect with the face. One feature of that is that you can change or remove the effect by changing or removing (setting to nil) the property in the face spec. Only text that has that face is to be affected. Perhaps it is that part that you have not yet grasped. > > > . 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". >=20 > Text properties that have no effect on display are not handled by the > display engine. They are handled by the features which implement the > effects of those text properties. For example, the read-only property > is handled by code that modifies the buffer text: that code > specifically examines the text to be modified, and if it has the > read-only property, that code signals an error. Under your proposal, > the code which implements the read-only property will now have to > examine face attributes of the text to be modified, in addition to the > text property. Correct. I made that clear in my sketch of checking the "effective" text-property value: any face property on the text would need to be checked in priority, to handle its text-property attributes, if there are any. > And the same will have to happen with every feature which supports > some text property. Correct. > This additional handling of face attributes will > have to be replicated in every such feature; Correct - for every such feature we decide to support. > there are no single place > to do that for all of them, AFAIU. This is clearly additional > non-trivial work, to be repeated in many Emacs features, which is a > disadvantage. Can you tell what would be the advantages that justify > these additional costs? I can't speak to the cost. You are doing so, which is good. Yes, if we want to support a given text property then clearly we will need to update the code that supports that text property There is, however, no "requirement" that _all_ text properties be supported. I said clearly, in my first message: Any properties that either cannot be implemented or do not make sense for [associating with] faces would be excluded (i.e., ignored). But I'm guessing that most could be accommodated. In an extreme example (but I'd hope it wouldn't be so limited, even at the outset), support could be provided for only one or two text properties (e.g. `invisible') to begin with. Support for more could be added if/when we (and users) see that the support would be helpful. > > > 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. >=20 > The display engine doesn't apply face attributes in the sense that you > seem to use this terminology. It examines face attributes and > determines what typeface, colors, fonts, etc. to use to display the > characters which have those face attributes. IOW, the only output of > face attribute examination is the description of what should be on the > screen, and that description is then used by the terminal-specific > interface to actually display that on the glass. I didn't say anything about the display engine there. What would needs to be done in terms of the implementation I leave to those knowledgable in that. Whether existing code that "examines face attributes" should be extended to DTRT for this feature or some other code should be brought in to do that is not my concern. I'm outlining a user-visible feature, not designing its implementation. There may be no interest in the feature. Or there may be interest in it but it might be deemed unfeasible or too costly in terms of implementation. > Do you see how any face attribute that has no effect on display > will not be "applied" as part of this processing? I don't even know how to parst that question. Maybe try to rephrase it? > The output of this processing What processing are you talking about? > is not buffer text modified in some way, it's an entirely > different set of data structures which are not even visible from Lisp. > There simply isn't any place there to record the face attributes you > propose to add. Sounds like you're saying that it cannot be coded. Too bad, in that case. Anyway, you clearly are not interested in the idea, if you are not outright hostile to it. Since it would no doubt need your participation to be implemented I guess it's dead in the water.