From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Michael A. Shulman" Newsgroups: gmane.emacs.devel Subject: Re: [MMM] Re: narrow-to-here-document Date: Mon, 7 Jul 2003 16:45:41 -0700 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20030707234541.GC11786@schilling.ugcs.caltech.edu> References: <20030620141028.GA1331@math.berkeley.edu> <20030621.012632.74543482.jet@gyve.org> <3EF73468.1030503@yahoo.com> <84r85cw0rk.fsf@lucy.is.informatik.uni-duisburg.de> <200307040032.h640WhKL015234@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1057621611 7834 80.91.224.249 (7 Jul 2003 23:46:51 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 7 Jul 2003 23:46:51 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jul 08 01:46:47 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19Zfh1-000228-00 for ; Tue, 08 Jul 2003 01:46:47 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19Zfr6-0003cY-00 for ; Tue, 08 Jul 2003 01:57:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Zfge-0006Yj-DK for emacs-devel@quimby.gnus.org; Mon, 07 Jul 2003 19:46:24 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Zfg1-0006Xs-UY for emacs-devel@gnu.org; Mon, 07 Jul 2003 19:45:45 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Zfg0-0006XX-2D for emacs-devel@gnu.org; Mon, 07 Jul 2003 19:45:44 -0400 Original-Received: from schilling.ugcs.caltech.edu ([131.215.43.185]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Zffz-0006XP-Eu; Mon, 07 Jul 2003 19:45:43 -0400 Original-Received: by schilling.ugcs.caltech.edu (Postfix, from userid 3224) id E3A2160521; Mon, 7 Jul 2003 16:45:41 -0700 (PDT) Original-To: Stefan Monnier Mail-Followup-To: Stefan Monnier , Richard Stallman , emacs-devel@gnu.org, mmm-mode-discuss@lists.sourceforge.net Content-Disposition: inline In-Reply-To: <200307040032.h640WhKL015234@rum.cs.yale.edu> User-Agent: Mutt/1.4i Original-cc: Richard Stallman Original-cc: mmm-mode-discuss@lists.sourceforge.net X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:15473 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15473 On Thu, Jul 03, 2003 at 08:32:43PM -0400, Stefan Monnier wrote: > I think we need feedback from the mmm-mode people before making any > decision on such an issue. I haven't looked at mmm-mode recently, > but it used to try and deal with font-lock, indentation and stuff like > that. I'd actually expect them to need/want ad-hoc support from > font-lock.el (for example) but haven't heard anything (maybe they > complain about such things in their own .el files rather than here). Our current implementation is able to do reasonably well by using font-lock-fontify-region-function and font-lock-beginning-of-syntax-function, but we'd love to have better support from font-lock (and other packages) for this sort of thing. Thanks, Stefan, for crossposting to the mmm list, since I wasn't following emacs-devel. Briefly, the way mmm-mode works is to parse the buffer for regions that it thinks (based on its configuration) ought to be edited using a different major mode, and create overlays to mark those positions. (It's not currently as good as we'd like at updating these overlays dynamically as text is edited, but I believe this is just because no one has sat down to write good code to do it.) Then it uses post-command-hook to check which region the point is in and make the buffer look (almost) like it's in the associated major mode. It primarily does this by changing keymaps, syntax tables, and lots of other buffer-local variables. Some of these values are stored buffer-locally, and others region-locally (all managed manually, of course). I don't mean to co-opt this disucssion for mmm, since it started on a somewhat different (though related) topic. But a "wish list" of possible features in emacs to make mmm and related packages easier has been on my mind for a while, and the discussion has been moving in that direction. So here are a few things I think emacs could do to make this sort of stuff easier and more effective. 1. Have a "registry" of some sort for major modes, where they can store enough information for mmm to turn them on effectively in small regions. Currently, the way mmm finds out what local variables and so on to set for each mode is to create temporary buffers and save the values of individual local variables. Among other things, this requires mmm mode knowing about all local variables that any major mode could want to set, and so we have a huge list of what variables to look for and what modes to look for them in. In addition, some major modes expect things like a file name set in all buffers, so we have to do kludgy things to the temporary buffer to try to make them work. 2. Have some sort of built-in support for variables that are localized to a text region within a buffer, such as an overlay or a text property. I'm not sure how or if this would work in general, but it's effectively what mmm does already to some extent. In particular, some variables want to keep different values in different regions even of the same major mode, in particular variables that store the state of syntax parsing. This leads to... 3. Better support in the syntax parsing routines allowing the caller to specify starting and ending positions and states. One of our biggest problems is that submodes end up trying to parse their syntax beyond the beginning of their region and getting confused, so ideally we would be able to tell them where to start their parsing, and what state to start parsing in. Sometimes the start state needs to be a continuation of the end state of the previous region in that mode (as with some literate programming, PHP, etc.), but sometimes it ought to be an independent start for each region. This is similar to the 'syntactic realm' idea that David Kastrup suggested. I don't think we've tried using intangible properties, for the reasons mentioned and perhaps others, but Joe Kelsey has had some success using syntax-table text properties to make the text that's not supposed to be parsed be treated as a single word or as whitespace, as appropriate. Joe, want to comment? 4. Effectively the same thing for font-lock, which uses the syntax parsing functions but also its own parsing functions. In general we've had more success hacking around font-lock than around syntax, because font-lock provides more customization variables and its state is easier to understand. If we want to continue this discussion, should it stay crossposted, or only on emacs-devel? -- Michael A. Shulman http://www.ugcs.net/~shulman The goal of psychological, as of biological, development is self-realization, or individuation. But since man knows himself only as an ego, and the self, as a totality, is indescribable and indistinguishable from a God-image, self-realization... amounts to God's incarnation. -- Carl Gustav Jung