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 17:51:26 +0300 Message-ID: <83h92e93ip.fsf@gnu.org> References: <7a902f7b-d808-4d0f-8ff9-b8f07eaddf83@default> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1490626391 25203 195.159.176.226 (27 Mar 2017 14:53:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Mar 2017 14:53:11 +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 16:53:07 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 1csW0s-0004uo-VX for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 16:52:55 +0200 Original-Received: from localhost ([::1]:47141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csW0z-0006dM-4V for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 10:53:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csVzV-00065u-Mf for emacs-devel@gnu.org; Mon, 27 Mar 2017 10:51:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csVzR-00074q-Ol for emacs-devel@gnu.org; Mon, 27 Mar 2017 10:51:29 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csVzR-00074m-M3; Mon, 27 Mar 2017 10:51:25 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3746 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1csVzQ-0002Nu-W9; Mon, 27 Mar 2017 10:51:25 -0400 In-reply-to: <7a902f7b-d808-4d0f-8ff9-b8f07eaddf83@default> (message from Drew Adams on Sun, 26 Mar 2017 12:14:38 -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:213417 Archived-At: > Date: Sun, 26 Mar 2017 12:14:38 -0700 (PDT) > From: Drew Adams > > 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) 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? 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, 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. 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. Using the display engine for this job is also problematic in several other aspects: . 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. . 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. And of course, applications can invent any properties they like. 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. In addition, text property search will also become slower, for the same reason redisplay will become slower, as explained above. > 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. 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. > 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 How is this different from overriding attributes of a face by those of another face, something I believe you can do today?