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: Sun, 25 Mar 2007 18:48:09 -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 1174873784 28881 80.91.229.12 (26 Mar 2007 01:49:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Mar 2007 01:49:44 +0000 (UTC) To: "Emacs-Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 26 03:49:37 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 1HVeL3-0007Ue-5y for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2007 03:49:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVeNE-0001gP-HV for ged-emacs-devel@m.gmane.org; Sun, 25 Mar 2007 20:51:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HVeNC-0001eD-7l for emacs-devel@gnu.org; Sun, 25 Mar 2007 21:51:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HVeNA-0001Yk-4y for emacs-devel@gnu.org; Sun, 25 Mar 2007 21:51:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVeNA-0001YW-1n for emacs-devel@gnu.org; Sun, 25 Mar 2007 20:51:48 -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 1HVeKx-0000Xq-88 for emacs-devel@gnu.org; Sun, 25 Mar 2007 21:49:31 -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 l2Q1nSXB019301 for ; Sun, 25 Mar 2007 19:49:28 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2Q1iSBa025497 for ; Sun, 25 Mar 2007 19:49:27 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-72-199.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2560857361174873703; Sun, 25 Mar 2007 18:48:23 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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:68557 Archived-At: > > I can't believe it would be hard for font-lock to check if text it > > wants to work with has an ignore-me property. > > Nobody asks you to believe it would be hard. To show what I meant, here's a naive implementation that seems to work. 1. In font-lock.el, use this everywhere that `put-text-property' is used now: (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))))) 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))))) That is enough to get the behavior I described: putting a `font-lock-ignore' property on selected portions of text tells font-lock "hands off". Try it, for instance, with highlighting from `facemenu-set-face' (`M-o o') - see end of mail. I'm not suggesting these definitions should be used as is. They should be enough, however, to show what I meant. They should point out that the task is not that difficult, at least in terms of functionality. Or perhaps they will point out what I'm misunderstanding or missing - please let me know in that case. So far, this works OK for me. Caveats: a. These are obviously naive implementations, advancing only a character at a time. The functionality seems to be OK, but the performance could be improved. Perhaps `text-property-any' (or `-not-all') or `next-single-property-change' could be used to let `put-text-property-unless-ignore' process larger stretches of text at a time. b. So far, I haven't actually seen fontification being noticeably slower, but the modified version of `font-lock-default-unfontify-region' is unacceptably slow, for sure, with a large buffer. It can't simply remove properties from BEG to END in one fell swoop as the original version does. To obtain acceptable performance here, it would perhaps be appropriate to write another built-in (C) analogous to `remove-list-of-text-properties', but which allows for a similar test. c. This doesn't take care of any MATCHER functions that might be used in font-lock specs. Unless coded explicitly to be sensitive to property `font-lock-ignore', they would act as they do now. I think that's acceptable, but users would need to be made aware of that. d. There might be some boundary cases that would need to be tweaked. For instance, I imagine that (put-text-property pos pos ...) puts the property at position pos, but (put-text-property-unless-ignore pos pos ...) does nothing. I don't know whether the current uses of `put-text-property' in font-lock.el really need to treat the start=end case. If an Emacs developer were to implement something like this in a performant way and add it to Emacs, it would mean that facemenu and hilock highlighting could be used in font-locked buffers, which I think many users would appreciate. facemenu.el would also need a minor change to `facemenu-add-face', to put property `font-lock-ignore' on the text it highlights. hilock.el would similarly need tweaking. If you want to try this to see what it's like (including performance penalties), add this line to `facemenu-add-face': ;; Specify the selected frame ;; because nil would mean to use ;; the new-frame default settings, ;; and those are usually nil. (selected-frame)))) ++ (put-text-property part-start part-end 'font-lock-ignore t)) (setq part-start part-end))) Then load library library `font-lock+.el', which is essentially the code shown at the top. Use `M-o o' to highlight portions of text, and then turn font-locking off and on to see the effect and the performance. Alternatively, you can try it using library `highlight.el' and library `font-lock+.el'. Do (define-key ctl-x-map [(control ?y)] 'highlight), and then use `C-x C-y' to highlight (and unhighlight) text. Oh, and you will need to set `highlight-use-overlays-flag' to nil - the default value uses overlays, which font lock of course doesn't interfere with. The code is here: http://www.emacswiki.org/cgi-bin/wiki/font-lock%2b.el http://www.emacswiki.org/cgi-bin/wiki/highlight.el