From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: feature request: text property to prevent font-locking Date: Sun, 31 Aug 2014 09:03:48 -0700 (PDT) Message-ID: References: <8538cc4sv7.fsf@iznogoud.viz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1409501071 32741 80.91.229.3 (31 Aug 2014 16:04:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2014 16:04:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: Wolfgang Jenkner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 31 18:04:24 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XO7c7-0006nY-Ot for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2014 18:04:23 +0200 Original-Received: from localhost ([::1]:50368 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XO7c7-0000fA-Bq for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2014 12:04:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XO7bl-0000f0-Sk for emacs-devel@gnu.org; Sun, 31 Aug 2014 12:04:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XO7bc-0000Ti-9i for emacs-devel@gnu.org; Sun, 31 Aug 2014 12:04:01 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:22861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XO7bc-0000TU-2e for emacs-devel@gnu.org; Sun, 31 Aug 2014 12:03:52 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7VG3mPg017534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 31 Aug 2014 16:03:50 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7VG3lju012518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 31 Aug 2014 16:03:48 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7VG3kHB000712; Sun, 31 Aug 2014 16:03:47 GMT In-Reply-To: <8538cc4sv7.fsf@iznogoud.viz> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:173924 Archived-At: > font-lock-default-unfontify-region leaves alone any "alternative" > (defined in char-property-alias-alist) of the `face' text property. "Leaves alone?" It think it does the opposite: it removes its highlighting: it treats the alternative property like it treats `face' (and `font-lock-face'). But perhaps I misunderstand you. > In particular, this is how the font-lock-face text property works. Yes, and thanks for pointing that out, as it is not obvious how `font-lock-face' is handled by `font-lock-default-unfontify-region'. But again, IIUC, it does not "leave alone" `font-lock-face'd text. It does just the opposite: it unfontifies it. That's even worse wrt unhighlighting than not doing anything. If you do nothing, then text that you have applied `face' to will at least appear highlighted when you turn off `font-lock-mode'. By using your suggested "leave alone" approach, you give font-lock control over not only highlighting but unhighlighting, so your ad hoc highlighting will never show, whether font-lock is on or off. > Now, on the one hand, keyword fontification does not override > "alternatives" (except if the highlight pattern has an `override' > flag). This is because text-property-not-all recognizes them and > thus prevents font-lock-apply-highlight from adding a value for > the `face' property. Yes. That is the point, AFAICT, of `font-lock-face': to let you give font-lock control over some ad hoc highlighting. And yes, you can use an "alternative" property for the same thing. > On the other hand, some experimenting suggests that syntactic > fontification does override those "alternatives". Yes, I noticed that too. But beyond that: What you are describing is just the control that font-lock has over highlighting, and how one can give it control over additional, non-`font-lock-keywords' highlighting by using `font-lock-face' (or another property besides `face', designated as a `face' "alternative"). What I am talking about is the opposite: Not giving font-lock control over additional, ad hoc highlighting, but taking font-lock control away, for given ad hoc highlighting. I don't want turning font-lock on or off to affect the given highlighting at all. That's the point. It's not that I'm looking for a way to let font-lock control some non-`font-lock-keywords' highlighting. That we can do already, using property `font-lock-face'. (And my guess is that the fact that this is the only feature for ad hoc highlighting that is compatible with font-lock is a reason that we have seen an expansion of the use of `font-lock-face'. IOW, if you want some ad hoc highlighting, you are currently pretty much obliged to give font-lock control over it, by using that approach.) > > I want to apply some other text property to the highlighted text, > > to tell font-lock not to fiddle with it ("hands off this text"). >=20 > Remove it from the value of `font-lock-extra-managed-props'. Remove what? The highlighting property? It's `face', which is already not in `font-lock-extra-managed-props'. The default value of `font-lock-extra-managed-props' is nil (or it should be; and hopefully it will be again, after bug #18343 gets fixed). That's the point: font-lock should not "own" `face'. And it pretty much does currently. Whether it did in the beginning I don't know, but I kinda doubt it. Property `face' was not invented for font-lock, AFAIK. Font-lock is one application of the feature of faces; nothing more. But it does not play well with other uses of that feature - it is a sandbox bully. > tl; dr: Existing facilities reduce the problem to clashes with > syntactic fontification. That's your point, not mine. But yes, the feature I proposed lets you protect given text also from overriding by syntactic fontification.