From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.help Subject: Re: eLisp fontlock with mmm-mode Date: Thu, 11 Sep 2003 22:28:55 +0000 Organization: muc.de e.V. -- private internet access Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <7vsqjb.r5.ln@acm.acm> References: <151bebc0.0309030659.7ff80bb@posting.google.com> <3F561EAE.3030506@yahoo.com> <151bebc0.0309050702.b3a9555@posting.google.com> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1063360142 1121 80.91.224.253 (12 Sep 2003 09:49:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 12 Sep 2003 09:49:02 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Sep 12 11:48:59 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19xkXy-0001UA-00 for ; Fri, 12 Sep 2003 11:48:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 19xkVk-0002kB-OE for geh-help-gnu-emacs@m.gmane.org; Fri, 12 Sep 2003 05:46:40 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-han1.dfn.de!news-mue1.dfn.de!news-nue1.dfn.de!uni-erlangen.de!lmu.de!news.muc.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 76 Original-NNTP-Posting-Host: acm.muc.de Original-X-Trace: marvin.muc.de 1063359051 42570 193.149.49.134 (12 Sep 2003 09:30:51 GMT) Original-X-Complaints-To: news-admin@muc.de Original-NNTP-Posting-Date: 12 Sep 2003 09:30:51 GMT User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (Linux/2.0.35 (i686)) Original-Xref: shelby.stanford.edu gnu.emacs.help:116557 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:12478 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:12478 Joe Kelsey wrote on 5 Sep 2003 08:02:02 -0700: > Kevin Rodgers wrote in message > news:<3F561EAE.3030506@yahoo.com>... >> Joe Kelsey wrote: >> > Aside from that, support for mixed-mode buffers suffers in Emacs due >> > to limitations on the ability of using syntax tables for multiple >> > purposes in a buffer. The design of syntax tables implies that a >> > single syntax table controls an entire buffer in a single style. >> > mmm-mode attempts to get around this by "dynamically" switching >> > syntax tables as the point moves through various areas of a buffer. >> > One very noticable side effect involves the fact that when you set >> > up the syntax table for a particular sub-buffer, it changes the >> > entire buffer view. Until someone comes up with a way to >> > regionalize syntax tables, you just have to live with the "bleeding" >> > of syntax table-based font-locks between buffer regions. >> I thought that had already been done; from the Special Properties node >> of the Emacs Lisp manual: > Text properties apply to portions of the buffer and constitute the > basis of font-lock mode. The interaction between the global > syntax-table and text properties allow font-lock to operate in a > specific buffer. > mmm-mode works by segregating the buffer into overlay sections. As > the cursor moves outof one overlay and into another, it switches the > global syntax-table. > The syntax-table text property works differently from the global > syntax table in that it applies to a specific section of the buffer. > However, applying a syntax-table property to a specific section of > text also involves a lot of extra overhead and thus it doesn't come > cheaply. Joe, I take it the value you are giving to the syntax-table text property is a syntax-table, and you're giving this to the whole mmm section of the buffer in a single operation. What do you mean by "a lot of extra overhead"? Do you mean extra coding or sluggish performance? If the latter, do you have any quantitative feel for how bad the hit is? > I have experimented in mmm-mode with using the syntax-table text > property to make inactive overlays have specific properties to try to > make indenting work better in multi-mode buffers. You mean, you are setting the STTP to a harmless value (say the WS code)? In that case, how do you go about restoring the STTP value to what the major mode might have set it to? > Basically, nothing works perfectly. The global syntax-table doesn't > work completely satisfactorily in multi-mode buffers. Syntax-table > text properties involve enormous overhead and also do not work well > enough. Isn't this sort of thing one of the reasons the syntax-table TP was invented? Surely the overhead can't be that bad (at least, not in GNU Emacs - I've heard that it can cause significant performance hits in the other Emacs, though). > The real problem involves resolving the dichotomy between linear > editing and the discontinuous nature of multi-mode files. I don't > really have a perfect solution right now. It feels like we could do with some sort of support in the core for multiple sections. Something a bit like a region, or a narrowed section, but independent of them, inside of which font-locking, indentation and so on would be calculated. > /Joe -- Alan Mackenzie (Munich, Germany) Email: aacm@muuc.dee; to decode, wherever there is a repeated letter (like "aa"), remove half of them (leaving, say, "a").