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: font-lock-multiline for cc-awk. Date: Wed, 26 Apr 2006 09:55:52 -0400 Message-ID: <87k69c8nj1.fsf-monnier+emacs@gnu.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1146059794 32288 80.91.229.2 (26 Apr 2006 13:56:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 26 Apr 2006 13:56:34 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 26 15:56:27 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FYkV4-0000Zf-TQ for ged-emacs-devel@m.gmane.org; Wed, 26 Apr 2006 15:56:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYkV4-0007c1-FT for ged-emacs-devel@m.gmane.org; Wed, 26 Apr 2006 09:56:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FYkUt-0007bm-0z for emacs-devel@gnu.org; Wed, 26 Apr 2006 09:56:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FYkUr-0007ba-GQ for emacs-devel@gnu.org; Wed, 26 Apr 2006 09:56:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYkUr-0007bX-BT for emacs-devel@gnu.org; Wed, 26 Apr 2006 09:56:01 -0400 Original-Received: from [209.226.175.25] (helo=tomts5-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FYkXY-0005FA-6l for emacs-devel@gnu.org; Wed, 26 Apr 2006 09:58:48 -0400 Original-Received: from alfajor ([70.55.144.118]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060426135557.PLNO18394.tomts5-srv.bellnexxia.net@alfajor>; Wed, 26 Apr 2006 09:55:57 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id EF185D91CF; Wed, 26 Apr 2006 09:55:52 -0400 (EDT) Original-To: Alan Mackenzie In-Reply-To: (Alan Mackenzie's message of "Wed, 26 Apr 2006 07:37:54 +0000 (GMT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:53477 Archived-At: >> AFAICT the patch below converts cc-awk to use font-lock-multiline >> instead of an after-change-function. > You've rubbed out my after-change function! Heeeellllllllllpppppppp!! Well, it was just a sample patch. > In fact, it's a massive pain in the posterior that font lock erases these > text properties without getting permission from the major mode. Huh? font-lock only clears the syntax-table properties if you specifically ask it to manage that property (by setting font-lock-syntactic-keywords). > I don't want to mix up the syntax-table and f-l-multiline properties, > because they're very different things. On the contrary, they belong together: the font-lock-multiline accompagnies the syntax-table property to say "this syntax-table property depends on this chunk of text", so that if a part of this chunk of text is changed, the syntax-table property can be recomputed. > Doing so would weaken the > existing functions, which are strong single-purpose functions. To do > things this sort of way, I'd put in a new function > c-awk-set-fl-multiline-properties (a sister function to > c-awk-set-syntax-table-properties, with the same calling conventions). > The existing function loops round string/regexp/division sign constructs, > whereas the new one would be looping round lines. A multiline-line without strings or regexps doesn't need to be refontified atomically because none of the other patterns you use can span or depend on multiple lines of text. > They don't mix very happily. On the contrary: they belong together. > But mainly, I don't want to be applying f-l-m properties throughout the > region[*]. They should be applied only at the region boundaries when > these need extending, and only when font lock is enabled, since they serve > no purpose otherwise. > [*] As you're aware, I don't want to use f-l-m properties at all. But if > I must use them, I only want them where absolutely needed. Look, I'm just showing this code to try and get you to understand how font-lock-multiline properties work. It seems like you've been thinking much too hard about your a-c-f code and can't think outside of that setting. [ Reminds me of "a calculus of capabilities" and "alias types": they present a new way to guarantee the safety of "manual" memory management primitives. Contrary to previous appoaches (which tended to be very complex and incomplete or much too restrictive), they allow dangling pointers. Many people found it terribly difficult to believe to understand that a system that allows dangling pointers can be safe w.r.t manual memory management: all previous approaches cared about checking that "free" is safe, whereas those new approaches only care about checking that the memory access is safe: i.e. they simply disallow access after a "free" rather than disallow "free" if the object is still "live" (which they typically define as "reachable"). ] > Why not leave things alone until Richard has settled the whole matter? Of course, I didn't intend to apply the patch. Stefan