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: how to prevent font-lock from messing with a portion of text? Date: Mon, 26 Mar 2007 08:56:57 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1174924811 1892 80.91.229.12 (26 Mar 2007 16:00:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Mar 2007 16:00:11 +0000 (UTC) Cc: Emacs-Devel To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 26 17:59:55 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HVrbu-0004rg-KG for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2007 17:59:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVreA-0003Re-72 for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2007 11:02:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HVrcu-0001FY-Dd for emacs-devel@gnu.org; Mon, 26 Mar 2007 12:00:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HVrcs-0001Bm-6E for emacs-devel@gnu.org; Mon, 26 Mar 2007 12:00:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVrcs-0001BZ-1L for emacs-devel@gnu.org; Mon, 26 Mar 2007 11:00:54 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HVrab-00027Z-FY for emacs-devel@gnu.org; Mon, 26 Mar 2007 11:58:33 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l2QFwUZU008678; Mon, 26 Mar 2007 09:58:31 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2QDu73O022487; Mon, 26 Mar 2007 09:58:29 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-81-70.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2562438071174924620; Mon, 26 Mar 2007 08:57:00 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:68623 Archived-At: > > (defun put-text-property-unless-ignore (start end property > value &optional > > object) > > "`put-text-property', but ignore text with property > `font-lock-ignore'." > > (let ((here (min start end)) > > (end1 (max start end))) > > (while (< here end1) > > (unless (get-text-property here 'font-lock-ignore object) > > (put-text-property here (1+ here) property value object)) > > (setq here (1+ here))))) > > This will still override a face on a word inside a string, because > (get-text-property 'font-lock-ignore object) will be nil. > You need to check for the presence of the property over the whole > start..end region. I have a string in an emacs-lisp-mode buffer. I highlight a word in the string using property `face' and I put property `font-lock-ignore' on it also. I turn font-lock on and off - the word highlighting stays. I modify the file and save it - the word highlighting stays. I highlight the whole string, or more than a word, with the highlighting starting or ending on or off a word boundary - the highlighting stays. I don't see the problem you mention. Could you explain the problem differently (e.g. recipe to test)? I no doubt misunderstand. > > 2. In font-lock.el, use this definition of > > `font-lock-default-unfontify-region': > > > (defun font-lock-default-unfontify-region (beg end) > > "Unfontify from BEG to END, unless text with property > `font-lock-ignore'." > > (let ((here (min beg end)) > > (end1 (max beg end))) > > (while (< here end1) > > (unless (get-text-property here 'font-lock-ignore) > > (remove-list-of-text-properties > > here (1+ here) (append font-lock-extra-managed-props > > (if font-lock-syntactic-keywords > > '(syntax-table face > font-lock-multiline) > > '(face font-lock-multiline))))) > > (setq here (1+ here))))) > > Same thing here, except even more so. Please give me a recipe to test. I don't say I don't believe you or that the code above is foolproof, but I'd like to see what the problem is. > Then the problem becomes that doing all those extra checks costs time, all > the time, for a feature which will be almost never used. I already spoke to performance. I don't claim that the above code is optimized. I intended it to show in general terms what I meant, so there was no misunderstanding about that. > OK, here's another option: don't change anything to font-lock, > don't fiddle > with it at all, just don't use text-properties to add your special faces. > Use overlays instead. Problem solved As I said, my own highlighting library uses overlays by default. But sometimes text properties are useful. Facemenu is one example. The differences that generally make overlays more useful for highlighting also mean that they are less useful in some contexts. The fact that copying and pasting text doesn't pick up overlays is one example: sometimes you might want the faces pasted. Every difference implies advantages and disadvantages. Text properties are associated with text; overlays are associated with buffer positions, and so on. This request is about letting a user-applied `face' property play well with font-locking. That's all. As I said, I'm not glued to any particular mechanism or implementation for allowing that. If it can be proven that any reasonable implementation would slow things down unacceptably, then an option could be used to turn on the more costly behavior. As it stands now, any application that uses the `face' text property gets that highlighting trampled on by font lock - there is no simple way for an application to prevent that. That, to me, is undesirable.