From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Idea: Be able to use text properties as face attributes Date: Mon, 27 Mar 2017 21:52:05 +0300 Message-ID: <8360iu8sdm.fsf@gnu.org> References: <<7a902f7b-d808-4d0f-8ff9-b8f07eaddf83@default>> <<83h92e93ip.fsf@gnu.org>> <8080a162-700f-42cc-aec9-5fdd7c646297@default> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1490640777 2950 195.159.176.226 (27 Mar 2017 18:52:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Mar 2017 18:52:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 27 20:52:53 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 1csZl7-0000J1-Gj for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 20:52:53 +0200 Original-Received: from localhost ([::1]:48516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csZlD-0001Yp-HO for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 14:52:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csZkd-0001Yi-Cj for emacs-devel@gnu.org; Mon, 27 Mar 2017 14:52:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csZkZ-0000m5-2m for emacs-devel@gnu.org; Mon, 27 Mar 2017 14:52:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csZkY-0000m1-WE; Mon, 27 Mar 2017 14:52:19 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3952 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1csZkW-0002dh-8f; Mon, 27 Mar 2017 14:52:18 -0400 In-reply-to: <8080a162-700f-42cc-aec9-5fdd7c646297@default> (message from Drew Adams on Mon, 27 Mar 2017 09:22:23 -0700 (PDT)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:213425 Archived-At: > Date: Mon, 27 Mar 2017 09:22:23 -0700 (PDT) > From: Drew Adams > Cc: emacs-devel@gnu.org > > > > 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) > > > > Some comments/questions about this: > > > > 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) 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. > And this is not about actually putting a text property on the text. > This is about getting that effect without doing that. 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? > > . 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". 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. And the same will have to happen with every feature which supports some text property. This additional handling of face attributes will have to be replicated in every such feature; 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? > > 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. 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. Do you see how any face attribute that has no effect on display will not be "applied" as part of this processing? The output of this processing 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.