From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: how to prevent font-lock from messing with a portion of text? Date: Mon, 26 Mar 2007 15:11:57 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1174936348 6413 80.91.229.12 (26 Mar 2007 19:12:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Mar 2007 19:12:28 +0000 (UTC) Cc: Emacs-Devel To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 26 21:12:17 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 1HVubs-0004qY-E2 for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2007 21:12:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVue8-0006Wn-PV for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2007 14:14:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HVue5-0006SK-58 for emacs-devel@gnu.org; Mon, 26 Mar 2007 15:14:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HVue4-0006QQ-FF for emacs-devel@gnu.org; Mon, 26 Mar 2007 15:14:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVue4-0006Pk-BF for emacs-devel@gnu.org; Mon, 26 Mar 2007 14:14:20 -0500 Original-Received: from tomts40.bellnexxia.net ([209.226.175.97] helo=tomts40-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HVubm-0002Tt-U8 for emacs-devel@gnu.org; Mon, 26 Mar 2007 15:11:59 -0400 Original-Received: from ceviche.home ([70.55.83.113]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070326191157.TODJ1624.tomts40-srv.bellnexxia.net@ceviche.home> for ; Mon, 26 Mar 2007 15:11:57 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id A01E4B4FD9; Mon, 26 Mar 2007 15:11:57 -0400 (EDT) In-Reply-To: (Drew Adams's message of "Mon\, 26 Mar 2007 08\:56\:57 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.96 (gnu/linux) X-detected-kernel: Solaris 8 (1) 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:68630 Archived-At: >> > (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. Sorry, I misread your code. I didn't pay attention to your loop. Boy, this is way too inefficient. You can make it a bit better using next-property-change, at least. But still, the performance impact is a problem, because the benefit is so small. > 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. There's no misunderstanding. >> 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. I don't see any reason why facemenu should use text-properties rather than overlays. > 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. We all agree. The differnece is whether we consider it sufficiently serious to warrant action and performance penalties. Stefan