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:36 -0700 (PDT) Message-ID: <403a3ff2-464f-4eb5-9843-60592e786955@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>> 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 1490737211 32684 195.159.176.226 (28 Mar 2017 21:40:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2017 21:40:11 +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 Tue Mar 28 23:40:05 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 1csyqJ-0006zI-FL for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 23:39:55 +0200 Original-Received: from localhost ([::1]:55388 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csyqN-0006I4-PS for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 17:39:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csyqE-0006Hr-9t for emacs-devel@gnu.org; Tue, 28 Mar 2017 17:39:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csyqC-0004zX-GG for emacs-devel@gnu.org; Tue, 28 Mar 2017 17:39:50 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:41649) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1csyq6-0004y8-PU; Tue, 28 Mar 2017 17:39:43 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2SLdcMK030108 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Mar 2017 21:39:40 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v2SLdcEb011369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Mar 2017 21:39:38 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 v2SLdbE2013974; Tue, 28 Mar 2017 21:39:37 GMT In-Reply-To: <<83shlx782i.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: 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:213465 Archived-At: > > I have no idea where in the Emacs code particular text > > properties are handled. Some code, somewhere, takes care > > of implementing their effects. >=20 > I tried to explain that with the example of the 'read-only' property. > In a nutshell, every text property has special code somewhere in Emacs > that examines that property to modify the behavior of the feature as > the property instructs. The only common infrastructure for that is > the code which allows Lisp programs to add, remove, modify, and > examine text properties at some position in a buffer or a string. the > effect of each property must be coded separately for every property. You already made that clear. And I already confirmed that updates to the separate treatments for the different properties would be needed. Wherever the code is that handles a given text property, if we decide that face specs should support that text property then that code would need to be updated to DTRT for it. > > 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. >=20 > Not sure what you mean by "update" here. The realization of the > effect happens when the corresponding feature is used, so it isn't > time-driven, it's event-driven. For face attributes that affect > display, that event is the next redisplay cycle, but for the > non-visual attributes you propose the events will be entirely > different, like buffer text modification for 'read-only'. Right. If it is an event such as buffer text modification that checks text property `read-only' for the text where the modification attempt is made, then the code that makes that check during the modification attempt would need to first check for a face property with a non-nil `read-only' pseudo face attribute. If present, it would do what it normally does for a non-nil `read-only' text property (e.g. raise an error). For a property such as `keymap', the code that handles a key sequence would need to check, first, for a face property at point, to see if that property has a `keymap' (pseudo) attribute, and if so, and if that key sequence is bound in that map, do what it would do if the key were bound in a `keymap' text property at that position. The _code to check for the property_ would be the same, for whatever property and wherever it might occur. It would be similar to what I showed before: check first for property `face', `font-lock-face', or `mouse-face' with a pseudo attribute that is the same as the text property to check. If none, then go ahead and check (as now), using code used now (presumably something similar to or a C equivalent to `get-text-property'). The code to check for the property would be the same for any property. But the code that handles the property, if found, would be different for each property, of course. That handling code would likely be the same as today (no change or little change). > Yes, I did grasp that. But this single rationale is > in effect a convenience feature, nothing more. I don't mind if you put it that way. All of Emacs is convenience features... This feature lets you do some things that you cannot easily do now. Call that convenience, if you like. > It doesn't explain why this is > more convenient than just putting the corresponding properties on > those same stretches of text, nor why you'd like to avoid actually > placing text properties to achieve the same goal. Again, yes it does. As I said, you need only change the pseudo attribute value to nil in the face spec to undo the change. That undoes the change ONLY for the face occurrences. =20 Likewise, for not undoing but changing to a different property value (assuming several are possible). 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. Probably the most commonly used text property is `face' or `font-lock-face'. Let users take advantage of those zones that are already mapped out, applying and changing other text properties there. > Nor does it explain > why the face property is being suggested as the vehicle > for providing this feature. > 'Face' is just one of the many text properties we > support, and there's nothing in it that would make it a > better means for implementing your convenience feature. This convenience feature is all about using the face occurrence locations. We have them. We could use them, in this way (and possibly in other ways). > At least I don't see why 'face' is better than any other > property. Well, it's the only property that makes sense for acting on face locations (duh). It lets you take advantage of those locations, whether they are there from font-locking or from ad hoc highlighting. It lets you give such ways of highlighting the ability to indirectly control other text properties. Whether you use font-lock highlighting or you highlight by dragging the mouse over text (a "marking-pen" highlighter) or you highlight in some other way, you will be able to leverage the highlighting to act on other text properties in highlighted zones. > For example, would it work > for you if we define a new text property, whose attributes will have > the same effect as the corresponding text properties. Would that be > as good as your 'face'-based proposal? If not, why not? See above. The point is to be able to take advantage of existing highlighting (text properties, not overlays). > > > 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 justify > > > that these additional costs? > > > > I can't speak to the cost. >=20 > I didn't ask you to. What I did ask is what are the user-level > advantages which would justify those costs, whatever they are. I > don't think you answered that question. I've described the point of the feature - the advantages. You've hinted at the cost. Do the advantages outweigh the cost? I have no idea, because I don't know the costs. And even if I did, my or your or John Doe's opinion of whether the advantages outweigh the costs might well be different. And I won't be doing the C development work, so my opinion about the worthiness relative to the cost is not so useful. I can't speak to the question of relative weight because I don't appreciate the cost. I can't speak to matters that involve the cost - sorry. > Such an answer is part of the > rationale for the proposed changes; the absence of the answer is what > makes it hard for me to understand the rationale, which is a > prerequisite for reasoning about it. You say that you have gotten the point, but I'm not sure you have. Asking "why faces?" really makes me wonder, at this point. If you have gotten the point then you see the utility of the proposal. Weigh that against the costs you see in whatever way you see fit. > > 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. >=20 > Invisible is actually the odd one out, since it _is_ implemented by > the display engine. It's all the rest that puzzle me. It's no different wrt other properties in regard to the question raised: We could decide to support only `read-only' or only `keymap' or only this and that, or whatever. The point there was to make clear that your assumption that I'm demanding that _all_ text properties be supported (all or none) is off the mark. Quite the contrary, as I stated from the beginning. It is important that any text properties that are not supported be at least tolerated (ignored) as face attributes, just as unknown (e.g. user-defined) text properties are ignored by Emacs. The point is to try to (1) make Emacs ignore unknown face (pseudo) attributes, in general (put in place the necessary infrastructure), and then possibly (2) begin to support active handling of one or more of them. > > I'm outlining a user-visible feature, not designing its > > implementation. >=20 > I'm asking you to provide the rationale for the feature, > and for attaching this feature to faces. I believe I've done so, several times now: Be able to leverage face locations (occurrences) and highlighting commands/features and face-attribute commands, to (in effect) control other text properties at those locations. > So far you provided only a single > rationale, for a single use case of the feature, Dunno what you see as the single rationale, or the single use case. You can easily highlight zones of text in several ways. Many zones are highlighted by font-locking, for instance. A user or a program can want to do things to/with such zones - things that involve text properties. Is that one use case or a thousand use cases? One rationale or many? > I'm asking to provide more use cases and at least > some arguments for attaching this feature to faces. I have nothing more to offer than what I've described. Apparently that is both (a) too restrictive ("only one") and too general - too complicated to implement. Sorry, but I can't add more to describe the feature as I see it. Or if I can, please let me know what it is that would help understanding. > > Sounds like you're saying that it cannot be coded. >=20 > No, I didn't say that. I'm saying that I still don't understand why > it would make sense to provide such a feature, and why we should > attach it to faces. Please help me understand your reasons. Does what I've said above, which repeats what I've said in pretty much each mail so far, help? If not, I'm afraid I can't help you see better what is involved. > > Anyway, you clearly are not interested in the idea, > > if you are not outright hostile to it. >=20 > At this point, I'm interested in understanding the idea. Only then I > will be able to make up my mind about it. I'm not there yet. Clearly. To be clear, in case it makes any difference: I have no "ulterior" motive in suggesting this idea. It just happened to occur to me out of the blue, and the more I thought about it the more I thought it was interesting and could be useful. Others can certainly think differently about it. I lose nothing particular if it is not implemented. If it is implemented I'm pretty sure that I would use it. I don't know just how/where I would use it. It would be a new feature that I would need to discover the practical use of, just like anyone else.