From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.help Subject: Re: eLisp fontlock with mmm-mode Date: Fri, 12 Sep 2003 22:39:23 GMT Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <151bebc0.0309030659.7ff80bb@posting.google.com> <3F561EAE.3030506@yahoo.com> <151bebc0.0309050702.b3a9555@posting.google.com> <7vsqjb.r5.ln@acm.acm> <151bebc0.0309120746.1820d513@posting.google.com> <6cftjb.ck.ln@acm.acm> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1063406899 23855 80.91.224.253 (12 Sep 2003 22:48:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 12 Sep 2003 22:48:19 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Sep 13 00:48:17 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 19xwi9-0006bL-00 for ; Sat, 13 Sep 2003 00:48:17 +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 19xwg7-00050r-FI for geh-help-gnu-emacs@m.gmane.org; Fri, 12 Sep 2003 18:46:11 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.ca!charlie.risq.qc.ca!53ab2750!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-NNTP-Posting-Host: 132.204.26.236 Original-X-Complaints-To: abuse@umontreal.ca Original-X-Trace: charlie.risq.qc.ca 1063406363 132.204.26.236 (Fri, 12 Sep 2003 18:39:23 EDT) Original-NNTP-Posting-Date: Fri, 12 Sep 2003 18:39:23 EDT Original-Xref: shelby.stanford.edu gnu.emacs.help:116574 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:12494 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:12494 > syntax-table properties are in constant use in AWK Mode (also part of CC > Mode). I've never felt they impacted the performance significantly, even > on my 166 MHz dinosaur. But, then again, large AWK buffers are rare. My They are also heavily used in CPerl-mode and also (tho less heavily) in many other major modes. The performance impact should indeed be small in general. In typical uses, the main performance impact is the time taken to compute/add the properties themselves, not the time to look them up during parsing. > OK. This approach rules out the use of the syntax-table property by > major modes, if they are to be used in MMM Mode. :-( Unless the major mode uses font-lock to add those properties and mmm-mode is careful to tell font-lock to re-adorn the syntax-table properties when needed. > Maybe it would be possible to adapt the core to support several ST text > properties simultaneously (e.g. syntax-table, syntax-table-cc, > syntax-table-mason, ....), and to setq parse-sexp-lookup-properties to > one of these symbols rather than simply t. It's probably easier to use overlays. >> Unfortunately, indentation engines and font-lock engines, at least as >> implemented by cc-mode, rely on a combination of syntax-table >> properties and regular expression searching to accomplish their tasks. > "Unfortunately"? How else could CC Mode do it? Using syntax-tables only. But yes, that would be somewhere between impossible and very painful. >> For example, take a noweb file. This consists of a literate program, > As an aside, could you explain what a "literate progam" is, exactly? > What it's for, who uses it, and so on. It a coding style that thinks of a source file as "description of the program, interspersed with the actual code" rather than "the code interspersed with comments". You can typically run the file through TeX to get a beautifully typeset description of your code, or you run it through some other filter to extract the actual code and then compile it. It might look like: ... \section{Parsing the input} To parse the input we define a \emph{function} \kw{foo}: \begin{code} void foo (int a, int b, char *c) { ... } \end{code} ... So you need both latex-mode and c-mode in the same buffer. > analyzing then in the backwards direction (necessary for doing the > indentation) is even harder than in the forwards direction (like a > compiler does). I see you've learned the secret ;-). Stefan