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: Mon, 27 Mar 2017 13:01:34 -0700 (PDT) Message-ID: <93aa220a-35c8-4be1-bfb5-299c46c9eba9@default> References: <<<7a902f7b-d808-4d0f-8ff9-b8f07eaddf83@default> <30d920b0-e1de-497d-98de-8b69e835e855@default>>> <<<30eb5a49-2d98-4f37-8f8c-32a88cd76827@default>>> <<<83bmsm938f.fsf@gnu.org>>> <<7f98847c-9b5e-47cf-85f2-247c2045d0af@default>> <<834lye8s1k.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 1490644929 29764 195.159.176.226 (27 Mar 2017 20:02:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Mar 2017 20:02:09 +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 Mon Mar 27 22:02: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 1csapr-0005sd-L3 for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 22:01:51 +0200 Original-Received: from localhost ([::1]:48735 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csapu-0001rW-Mu for ged-emacs-devel@m.gmane.org; Mon, 27 Mar 2017 16:01:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csapm-0001rJ-Rg for emacs-devel@gnu.org; Mon, 27 Mar 2017 16:01:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csapl-00071C-P7 for emacs-devel@gnu.org; Mon, 27 Mar 2017 16:01:46 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:26236) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1csaph-0006t8-Tj; Mon, 27 Mar 2017 16:01:42 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2RK1b3K025522 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 27 Mar 2017 20:01:38 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v2RK1bxK002652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 27 Mar 2017 20:01:37 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v2RK1adr031365; Mon, 27 Mar 2017 20:01:37 GMT In-Reply-To: <<834lye8s1k.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: userv0022.oracle.com [156.151.31.74] 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:213433 Archived-At: > > The idea of the feature is that a face property that > > contains text properties as (pseudo) face attributes > > would produce the same effect as applying those text > > properties to the text. But those text properties > > would not in fact be applied to the text - they would > > remain encapsulated in the value of the applied face > > property (`face', `font-lock-face', or `mouse-face'). >=20 > As I explained, the display engine, which is the part that implements > the faces, will be unable to do anything with attributes that don't > affect display. Yes, you explained that. Thanks. Does that mean that such code could not invoke _other_ code that _would_ be able to do something with those text properties (that masquerade in a face spec as face attributes)? > And the implementation of the features which do need > to pay attention to such attributes is entirely unrelated to faces. > So I don't understand why you want this to be attributes of faces. I think by now you should understand why I proposed the feature - its use. I've made that pretty clear. You are free to think that it's a useless feature, of course, and you are free to think that it might be useful but is not feasible to implement. > Moreover, you consistently mention the display engine as the main part > of this proposal. See my replies to your (repeated) diatribes about my mistakenly referring to the "display engine". I was only trying to describe the desired feature, not to speak to which code really would, could, or should implement it. Mille excuses for having naively invoked the terms "redisplay" and "display engine". > But features that don't affect display cannot be > usefully built on top of the display code, because the display code is > designed to run and examine text only when and where there's likely to > be changes in buffer text that will affect the display. I suppose it is natural that you immediately go down the rabbit hole of thinking in terms of implementation. And that is no doubt helpful to the discourse overall. But it doen't really jibe with your claim not to understand what I mean by the feature itself and its raison d'etre. So far, anyway, I haven't noticed anyone else who has not gotten the point of the feature. (It is true that we've heard from only two other readers so far.) > By contrast, > the non display-related properties need to be processed regardless of > any changes that could affect display. Do you see a conflict here > between the goals and the proposed design? I didn't propose any design. And you've already made clear that you do not understand the goals. But I guess that doesn't stop you from seeing such a conflict. One more time: I do not pretend to know how this feature would, could, or should be implemented.