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: 12 Sep 2003 08:46:51 -0700 Organization: http://groups.google.com/ Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <151bebc0.0309120746.1820d513@posting.google.com> References: <151bebc0.0309030659.7ff80bb@posting.google.com> <3F561EAE.3030506@yahoo.com> <151bebc0.0309050702.b3a9555@posting.google.com> <7vsqjb.r5.ln@acm.acm> NNTP-Posting-Host: deer.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1063382787 21412 80.91.224.253 (12 Sep 2003 16:06:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 12 Sep 2003 16:06:27 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Sep 12 18:06:25 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 19xqRF-0006bu-00 for ; Fri, 12 Sep 2003 18:06:25 +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 19xqMl-0003Wr-0k for geh-help-gnu-emacs@m.gmane.org; Fri, 12 Sep 2003 12:01:47 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 109 Original-NNTP-Posting-Host: 207.246.150.92 Original-X-Trace: posting.google.com 1063381622 15301 127.0.0.1 (12 Sep 2003 15:47:02 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: 12 Sep 2003 15:47:02 GMT Original-Xref: shelby.stanford.edu gnu.emacs.help:116561 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:12482 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:12482 Alan Mackenzie wrote in message news:<7vsqjb.r5.ln@acm.acm>... > Joe Kelsey wrote on 5 Sep 2003 08:02:02 > -0700: > > Kevin Rodgers wrote in message > > news:<3F561EAE.3030506@yahoo.com>... > > Joe Kelsey wrote: > > 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? The maintainer of mmm-mode felt that turning on parse-sexp-lookup-properties might impose unacceptable overhead on buffer activities. I have no direct evidence of any performance penalties due to turning on parse-sexp-lookup-properties, but I bow to the owner of mmm-mode in his personal decisions. > > 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? I created a function to apply a syntax-table property to a set of regions like this: (defun mmm-space-other-regions () "Give all other regions space syntax." (interactive) (mmm-syntax-other-regions (string-to-syntax " ") nil) (setq parse-sexp-lookup-properties t)) which eventually calls the following on each region (the definition of mmm-syntax-other-regions does not matter to this discussion): (defun mmm-syntax-region (start stop syntax) "Apply a syntax description from START to STOP using the syntax cell SYNTAX. Sets the local text property syntax-table to SYNTAX in the region. If SYNTAX is nil, then remove local syntax-table property." (if syntax (add-text-properties start stop (list 'syntax-table syntax)) (remove-text-properties start stop '(syntax-table nil)))) > > 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. You seem to feel that some sort of "narrowing" function might work. However, in reality, when you look at multi-mode buffers as supported by mmm-mode, narrowing by itself does not provide enough context. Unfortunately, indentation engines and font-lock engines, at least as implemented by cc-mode, rely on a combination of syntax-tasble properties and regular expression searching to accomplish their tasks. For example, take a noweb file. This consists of a literate program, actually a mixture of LaTeX and code in what Norman Ramsey calls "chunks". Each documentation chunk describes ideas behind surronding code chunks. Part of the literate programming style involves the tangle and weave processes. Tangling means reassembling the disjoint code chunks from a web file into a choerent whole for presentation to the compiler. Weaving involves processing the entire web to markup sections appropriately, applying pretty-printing markup to the code and adjusting the web syntax markup to fit the documentation processor, such as LaTeX or HTML. While editing such buffers, you want to present different views of the buffer in different sections. For instance, if you want to edit the documentation, then you want latex-mode to treat the code chunks as a single unmovable piece, essentially a syntactic word and not attempt to reformat it using its own peculiar ideas of paragraph formatting. Meanwhile, while editing code, you want cc-mode to completely ignore the documentation chunks. One of the most frustrating parts of this comes when cc-mode spots an unterminated apostrophe in a preceding documentation chunk and treats it as an unterminated string, thus compeltely screwing up the indentation of the code. Also, you may want to consider disjoint code sections as virtually appended to each other in order to carry forward indentation from one to the other. Also, you may want to ignore other code sections depending on how related they are to each other, since the tangle process may move them around into different places, including separating them into completely different files (.c versus .h). I want to have "virtual views" of a buffer imposed upon major modes in order to restrict how far afield their regular expression linear searches can carry them. Thus, I want to specify a set of regions which cc-mode can consider virtually catenated in order to restrict it to only looking at characters in that view. Then it can use all of the regular-expression optimizations to supplement syntax-table properties it wants in order to work correctly in multi-mode buffers. Something like narrow-to-region, but given a list of disjoint regions to narrow to. /Joe