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: Wed, 29 Mar 2017 10:06:52 -0700 (PDT) Message-ID: <4dbf9e54-d634-4a4d-ad5a-4c2b4e318acf@default> References: <<<<<7a902f7b-d808-4d0f-8ff9-b8f07eaddf83@default>>>>> <<<<<83h92e93ip.fsf@gnu.org>>>>> <<<<8080a162-700f-42cc-aec9-5fdd7c646297@default>>>> <<<<8360iu8sdm.fsf@gnu.org>>>> <<<19e94d18-656f-4a8f-8843-4d46ffdd037b@default>>> <<<83shlx782i.fsf@gnu.org>>> <<403a3ff2-464f-4eb5-9843-60592e786955@default>> <<83a8846srr.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 1490807242 28393 195.159.176.226 (29 Mar 2017 17:07:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 29 Mar 2017 17:07:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 29 19:07:18 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 1ctH3s-0005xq-Mi for ged-emacs-devel@m.gmane.org; Wed, 29 Mar 2017 19:07:08 +0200 Original-Received: from localhost ([::1]:60105 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctH3y-00086m-Kt for ged-emacs-devel@m.gmane.org; Wed, 29 Mar 2017 13:07:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctH3o-00084O-Jc for emacs-devel@gnu.org; Wed, 29 Mar 2017 13:07:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ctH3m-0007xk-W9 for emacs-devel@gnu.org; Wed, 29 Mar 2017 13:07:04 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:43354) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ctH3i-0007rd-2f; Wed, 29 Mar 2017 13:06:58 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2TH6us1016218 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Mar 2017 17:06:56 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v2TH6tje019667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 17:06:55 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v2TH6r3A011676; Wed, 29 Mar 2017 17:06:54 GMT In-Reply-To: <<83a8846srr.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: aserv0022.oracle.com [141.146.126.234] 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:213505 Archived-At: > > That's the point. The text-property fiddling is confined > > to a particular face. It affects all occurrences of the > > face (or all on a given frame, optionally). > > > > That's one advantage. Another is that we have commands > > that let users easily apply faces to text in various ways > > (match regexps,... whatever). Another is that users > > already have lots of locations where faces are applied - > > common and significant locations, for users. So this > > feature has plenty of terrain of immediate application. >=20 > Why would I want to make all stretches of text that have, say, > font-lock-constant-face have a particular 'keymap' attribute? Dunno why you would, Eli. Maybe you wouldn't. I probably wouldn't (why would I?). But you might want to use font-lock to place a `keymap' property on particular zones of text, defined syntactically. IOW, you might want to take advantage of font-lock's elaborate specification possibilities to locate places to put a given `keymap' property. Yes, you can also do that now, by giving a spec to font-lock that contains the text properties, and adding those properties to `font-lock-extra-managed-props'. The proposed feature provides more flexibility for that kind of thing. You can change a face's spec anytime, to change the effects for only _that face's_ occurrences. A face need not show any highlighting, even now (its attributes could just reflect the default face). With the proposed feature a face could certainly provide _only_ non-face text properties, if that makes sense in a given context. E.g., a given font-lock spec could have as its purpose to _only_ place a given `keymap' (or `syntax-table' or whatever) property at particular locations, defined syntactically. (Again, you could get that effect now, using `font-lock-extra-managed-props', but without the flexibility just mentioned.) And beyond font-locking, there are lots of other ways to "highlight" text with a given face. And for such ad hoc highlighting you do not necessarily want the highlighting (including application of other text props) to go away just because you turn off font-lock mode. Highlighting is more general than just font-locking. Since with the proposed feature a face can be a carrier of text properties, the notion of "highlighting" using a face takes on more meaning. Highlighting in the usual sense might be one of the effects - or not. Text properties, besides just those affecting appearance, can now be part of any "highlighting". When I said "users already have lots of locations where faces are applied - common and significant locations" I wasn't referring only to using locations that were chosen for text highlighting in the ordinary sense. I mean both that those face occurrences _can_ be taken advantage of and that _non-highlighting occurrences_ of a face can also exist. The meaning of "places where faces are applied" is expanded. > And how is that more convenient than simply scanning the text > for the same regexp/syntax as the one which used to place the > face and actually putting a 'keymap' property there? Do you ever use font-lock? How is it more convenient for you that explicit code that searches for each regexp/syntax construct and puts the relevant face on it? Clearly it is, no? Likewise, for the many other ways of highlighting text. There are convenient ways to highlight text, but you aren't forced to use them. If you prefer to always "simply" scan the text and apply a face, you are free to do that instead.=20 > And why do you only ask this for the 'face' > properties, but not for others? I've answered that several times now. It's hard to believe that you are really trying to get the message. If you cannot see the convenience of being able to apply text properties just by using existing means of highlighting (and not just font-locking) then I don't think there's a lot more I can do to convince you.=20 > IOW, I'm still struggling to understand why you > attach this feature to faces, and to faces only. Yeah, you keep asking me that. And I keep telling you my reasons, in different ways - but the reasons remain the same. Do you see something besides faces that offers the same convenience for applying properties to text? I proposed leveraging faces, but if you see another potential affordance for doing that, maybe we can consider that one too. > Please also note that at least font-lock faces are by > default placed lazily, on and around the portions of > the buffer that are going to be displayed. So Lisp > programs looking for your special attributes might not > find them if JIT font-lock didn't yet fontify them. Yes, by default font-locking is lazy. That would of course apply also to the use of a face whose spec contains text-property (pseudo) face attributes, as well as to any other face. And just as you see text fontified when it becomes exposed in the window, so would the text props in its face be realized as the text becomes exposed in the window. You cannot use a property such as `keymap' without moving point to the text that has that property, in which case the text is also shown in the window. If there are any text props (that we decide to support for this feature) for which lazy realization is not good enough then they wouldn't be good candidates for use by font-lock (unless font-lock is used by the user eagerly instead of lazily). > Am I correct concluding that the advantages, from your POV, > are that users of this feature will be able to avoid the > need of specifying the text to receive this special > treatment with regexps, syntax classes, and other similar > means, and instead will be able to use the definitions > already provided for faces? By "this special treatment" are you referring to (effectively) applying non-face text props? And is "the text to receive" that treatment the text where faces are applied (in my proposal)? If so, then yes: Leverage the many convenient ways we already have to apply a face to zones of text. (Not sure what you mean there by "the definitions already provided for faces." Face definitions don't specify where the faces get applied.) > Is this the only advantage, or are there others? Is it one advantage or two (or several)? I said: I chose face properties not by accident, but because the feature would let you leverage both (1) existing face locations (occurrences), and (2) existing commands and other functions that let users and Lisp easily put a face property on text in various ways, or change it. Faces are special in those senses - they constitute especially handy affordances for manipulating text at ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ locations that are common or significant for users. It's about (indirectly) applying text props and manipulating applied text props, in convenient ways. Those are the advantages I see, for why we would turn faces into carriers of arbitrary text properties (at least those we decide to support). > > 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. >=20 > Why is it better than just put any property you need, > such as 'read-only', directly on that same text? What=20 >non-trivial parts of the job would be saved by using > face attributes instead? See above and my other replies. Faces are convenient. There is a lot more provided to users for highlighting (i.e., using faces) than there is for placing arbitrary text properties. And by encapsulating text props within a face we can easily manipulate different bunches of them individually. They are not just all `font-lock-extra-managed-props', i.e., handled all the same, together, wherever they are used. > > Faces are special in those senses - they constitute > > especially handy affordances for manipulating text at > > locations that are common or significant for users. >=20 > If this is the answer to my question above, It's part of the answer. Look above, and in previous replies, for more. > then I'm not sure I agree > with you. E.g., Text mode has no faces by default, but > that doesn't mean Lisp programs working in Text mode > won't want to manipulate text at significant locations. 1. I didn't say that this feature would or should be the only way for Lisp programs to manipulate text. 2. Wrt both Lisp and interactive use: Who cares what Text mode has by default? Please try to get beyond font-lock and especially beyond default font-locking. I can highlight text in Text mode in many ways helpful and meaningful to whatever current use I'm making of Text mode. That includes but is not limited to non-default font-locking. I use ad hoc highlighting all the time (with text props and with overlays). Sure, maybe some users don't, and maybe some users never fiddle with `font-lock-keywords'. No one would be forced to use this feature either.