From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: joe-gg@zircon.seattle.wa.us (Joe Kelsey) Newsgroups: gmane.emacs.help Subject: Re: eLisp fontlock with mmm-mode Date: 5 Sep 2003 08:02:02 -0700 Organization: http://groups.google.com/ Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <151bebc0.0309050702.b3a9555@posting.google.com> References: <151bebc0.0309030659.7ff80bb@posting.google.com> <3F561EAE.3030506@yahoo.com> NNTP-Posting-Host: deer.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1062792918 28957 80.91.224.253 (5 Sep 2003 20:15:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Sep 2003 20:15:18 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Sep 05 22:15:16 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 19vMzE-0006z6-00 for ; Fri, 05 Sep 2003 22:15:16 +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 19vMyg-0001ID-52 for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Sep 2003 16:14:42 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 46 Original-NNTP-Posting-Host: 207.246.150.92 Original-X-Trace: posting.google.com 1062774123 9581 127.0.0.1 (5 Sep 2003 15:02:03 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: 5 Sep 2003 15:02:03 GMT Original-Xref: shelby.stanford.edu gnu.emacs.help:116389 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:12308 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:12308 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. 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. 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. 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. /Joe