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 13:14:03 -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 1174940272 29897 80.91.229.12 (26 Mar 2007 20:17:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Mar 2007 20:17:52 +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 22:17:44 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 1HVvdO-0005IP-85 for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2007 22:17:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVvff-0001Mp-4J for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2007 15:20:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HVvdo-0008Fq-RX for emacs-devel@gnu.org; Mon, 26 Mar 2007 16:18:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HVvdm-0008D0-N3 for emacs-devel@gnu.org; Mon, 26 Mar 2007 16:18:08 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVvdm-0008Ci-GL for emacs-devel@gnu.org; Mon, 26 Mar 2007 15:18:06 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HVvbU-0001Mr-Mw for emacs-devel@gnu.org; Mon, 26 Mar 2007 16:15:44 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2QKFda8031658; Mon, 26 Mar 2007 15:15:39 -0500 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 l2QJwlVY018649; Mon, 26 Mar 2007 14:15:38 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by acsmt351.oracle.com with ESMTP id 2563035931174940044; Mon, 26 Mar 2007 13:14:04 -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:68633 Archived-At: > 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. Yes, I mentioned that (I mentioned `next-single-property-change', actually). > But still, the performance impact is > a problem, because the benefit is so small. It depends on what is observed in practice. I don't claim that others will observe the same in all contexts, but I don't notice any slowdown during fontification. There surely is a slowdown, because of the naive implementation, but I don't notice it. The question is, is the slowdown a problem in practice? I find that even buffers that were large (~500K chars) present no problem. And very, very, large buffers are not completely font-locked by default anyway. IOW, it's not clear that this would really affect what users perceive. As I mentioned, unfontifying is a different matter - there, the slowdown is noticeable and unacceptable, and a C implementation would be needed to compare with the current C implementation (`remove-list-of-text-properties'). > >> 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. Facemenu is an example. I suspect that there are good reasons that it uses the `face' text property (e.g. input of new text?), but I won't argue for or against that use. Applications other than facemenu, for whatever reasons, might well use property `face' for things other than font-locking. There's nothing that discourages them from doing that, and nothing should. Overlays are not a general replacement for text properties. As it stands now, applications cannot really do that and expect font lock to play well with them. That was my point in suggesting that we turn your (`persistant-face') suggestion on its head, and use a dedicated property for font lock - IOW, not have font lock use property `face' at all. That would be a solution that should have no performance penalty. The point is that font-lock today uses property `face', and so do/will other applications, and font lock is not a good neighbor, effectively erasing any `face' property (erase: the visual effect, not the property itself) that it does not "own". The solution, as I see it, is to either 1) move font lock to its own non-`face' property or 2) have some other mechanism to tell font lock "hands off!" a given portion of text. I'd prefer the former, for a variety of reasons; the latter is an ugly little hack, and entails some performance hits. > > 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. Cantoning font lock to its own text property (or properties) should not imply a performance penalty. Doing a `font-lock-ignore' workaround such as I suggested (but with an optimized implementation) is second best, AFAICT. I hope some solution to font lock's bad-neighborliness is found (after the release).