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: Tue, 28 Mar 2017 18:08:21 +0300 Message-ID: <83shlx782i.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1490713712 30119 195.159.176.226 (28 Mar 2017 15:08:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2017 15:08:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 28 17:08:26 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 1cssjM-0006jY-QC for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 17:08:20 +0200 Original-Received: from localhost ([::1]:53838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cssjS-0008KM-TF for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2017 11:08:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cssjM-0008K8-5j for emacs-devel@gnu.org; Tue, 28 Mar 2017 11:08:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cssjJ-00078J-El for emacs-devel@gnu.org; Tue, 28 Mar 2017 11:08:20 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51648) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cssjJ-00078F-Bt; Tue, 28 Mar 2017 11:08:17 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4923 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cssjI-0005Zv-Mi; Tue, 28 Mar 2017 11:08:17 -0400 In-reply-to: <19e94d18-656f-4a8f-8843-4d46ffdd037b@default> (message from Drew Adams on Mon, 27 Mar 2017 13:01: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:213453 Archived-At: > Date: Mon, 27 Mar 2017 13:01:38 -0700 (PDT) > From: Drew Adams > Cc: emacs-devel@gnu.org > > I have no idea where in the Emacs code particular text > properties are handled. Some code, somewhere, takes care > of implementing their effects. 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. > 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. 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'. > > > 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? > > 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. Yes, I did grasp that. But this single rationale is in effect a convenience feature, nothing more. 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. 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. At least I don't see why 'face' is better than any other property. 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? > > 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. 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. 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. > 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. Invisible is actually the odd one out, since it _is_ implemented by the display engine. It's all the rest that puzzle me. If 'invisible' is the only one, i.e. you are asking for a feature that would allow making text which has a certain face disappear from display, that could perhaps be implemented without introducing any face attributes. IOW, it's a much narrower goal, and we don't necessarily need to generalize it if no other use cases are apparent. > I'm outlining a user-visible feature, not designing its > implementation. I'm asking you to provide the rationale for the feature, and for attaching this feature to faces. So far you provided only a single rationale, for a single use case of the feature, and that use case can be catered to by different means which don't require any additional infrastructure. I'm asking to provide more use cases and at least some arguments for attaching this feature to faces. > Sounds like you're saying that it cannot be coded. 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. > Anyway, you clearly are not interested in the idea, if you are not > outright hostile to it. 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.