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:08:03 -0700 (PDT) Message-ID: <64c58be2-17e5-478c-ac0e-092adf17b768@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 1490807308 20668 195.159.176.226 (29 Mar 2017 17:08:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 29 Mar 2017 17:08:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 29 19:08:24 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 1ctH55-0004eM-4d for ged-emacs-devel@m.gmane.org; Wed, 29 Mar 2017 19:08:23 +0200 Original-Received: from localhost ([::1]:60109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctH5A-0000AH-JW for ged-emacs-devel@m.gmane.org; Wed, 29 Mar 2017 13:08:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctH50-0000A2-TU for emacs-devel@gnu.org; Wed, 29 Mar 2017 13:08:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ctH4w-0000Lq-JN for emacs-devel@gnu.org; Wed, 29 Mar 2017 13:08:18 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:44076) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ctH4r-0000J8-Pd; Wed, 29 Mar 2017 13:08:09 -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 v2TH876Q017793 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Mar 2017 17:08:07 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 v2TH86dh022759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Mar 2017 17:08:06 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v2TH84qs020736; Wed, 29 Mar 2017 17:08:04 GMT In-Reply-To: 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:213506 Archived-At: > > IOW, I'm still struggling to understand why you attach this feature to > > faces, and to faces only. >=20 > I may well be misunderstanding what Drew is asking for, because I didn't > understand it the first four times he explained it, either. But I think > he's asking for something that works like a face, but includes all text > properties. Yes. "Works like a face" is a good way to put it. It is what I meant by leveraging existing, convenient ways of applying (and unapplying), and specifying, faces. Wrt "includes all text properties": 1. At least _tolerates_ all of them, ignoring any that w decide not to teach Emacs to handle. 2. Includes _within a given face spec_. The face definition is used as an object that encapsulates a certain number of non-face text properties. Face A might use one value of text property `keymap', and face B might use another. In neither case would property `keymap' be applied directly to the underlying text where the face is applied. Only the face property is applied to the text (for this feature). This lets you remove or change property `keymap' for all occurrences of a given face. And it lets Lisp code distinguish properties that are attached directly to the text and are thus not dependent on any face from properties that are applied indirectly by way of the face. > That is: He wants to say > (defprop my-prop '(:read-only t :invisible nil :font "futura")) > (set-text-prop (point-min) (+ (point-min) 4) my-prop) > (set-text-prop (+ (point-min) 10) (+ (point-min) 20) my-prop) > and then > (set-prop my-prop :invisible t) Nope. That doesn't use faces at all. It just attaches the properties to the text directly. It in no way lets you leverage the features we have for applying faces, and it in no way bundles the properties within a face spec, so that changing the face changes (in effect) the properties of the text where the face is applied. > and then these two ranges would suddenly become invisible. > So it's like... a CSS selector... kinda. >=20 > The thing is, I think you can just cheat and this thing is already > available? That is, just make my-prop a list, apply that list to the > regions you are interested in, and then just mutate that list instead of > using the property functions? Or does set-text-properties copy > PROPERTIES before putting them on the text? I have neither tested nor > read the source code. See above. Yes, you can already apply text properties directly to text. That's not what this feature is about. And it's not only about being able to change a set of props that is applied at various locations (though yes, there is that effect from the proposal). It's also about taking advantage of face features, in particular, convenient ways to apply them. If you look at the fact that Emacs at one point added to font-lock the ability to "manage" (to some extent) other, non-face text properties, this feature is in a similar vein. Why did we add that extension to non-face props? Because font-lock provides a _convenient way to specify how and where to apply_ a property. Imagine that! Yep, font-lock applying a non-face property is "just a convenience". And a very convenient one, too. ;-) Do most users use it? Probably not. That doesn't mean we shouldn't have added it.