From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.help Subject: Re: Multiple Major Modes Date: Mon, 2 Nov 2009 13:32:24 +0100 Message-ID: References: <25d42153-4e90-4491-b0a0-7efff5215f35@k17g2000yqh.googlegroups.com> <87bpjmhrbh.fsf@liv.ac.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1257165270 13044 80.91.229.12 (2 Nov 2009 12:34:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Nov 2009 12:34:30 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: fx@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Nov 02 13:34:23 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N4w62-0007m3-U1 for geh-help-gnu-emacs@m.gmane.org; Mon, 02 Nov 2009 13:33:19 +0100 Original-Received: from localhost ([127.0.0.1]:60889 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4w62-0007do-41 for geh-help-gnu-emacs@m.gmane.org; Mon, 02 Nov 2009 07:33:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N4w5b-0007dP-B7 for help-gnu-emacs@gnu.org; Mon, 02 Nov 2009 07:32:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N4w5W-0007cg-IN for help-gnu-emacs@gnu.org; Mon, 02 Nov 2009 07:32:50 -0500 Original-Received: from [199.232.76.173] (port=45325 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4w5W-0007cd-C4 for help-gnu-emacs@gnu.org; Mon, 02 Nov 2009 07:32:46 -0500 Original-Received: from mail-yx0-f191.google.com ([209.85.210.191]:57596) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N4w5U-0000pG-Pe; Mon, 02 Nov 2009 07:32:44 -0500 Original-Received: by yxe29 with SMTP id 29so4696659yxe.14 for ; Mon, 02 Nov 2009 04:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=eKqwEaMrM6TZqkS2JwcqZfbdgbUg1mEyqqy/m+0jXyc=; b=NBEoXE+NM+qnybbhxjDa5W5G6wxJs/MLmqfl0Umjx8DLqVQuwtezshqjQmggkxwni5 jdo3Jiwbj9myZ9G3C4wrVKRhMJTxogpIzRE0shjRVoto9CmythZKFtwCcNQ9O1YsCDtI zclqRgS0GRWl+5pnwcHZCZoQW8wuK7+POYCu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=RAwu1kQnfC4gdZEpIxx8bzOZ7L2KM239xSvYu3hEUhg+ql2l2fDDgumszanpU0JEw4 pUtGfpfqkpIaFkLHl8NsjkddkO45lieVM0ntQQov7x9hrNKBMIFrIeMW8OSYwemmffBF 9nUdTAb/OiqpnHw+9ud02VwtEqV0lJhaYvfN8= Original-Received: by 10.101.170.11 with SMTP id x11mr104360ano.109.1257165164071; Mon, 02 Nov 2009 04:32:44 -0800 (PST) In-Reply-To: <87bpjmhrbh.fsf@liv.ac.uk> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:69392 Archived-At: On Sun, Nov 1, 2009 at 10:24 PM, Dave Love wrote: > > I'm rather baffled by this nxhtml thing referred to, and its complexity. > It claims to be trying to solve a problem that the indirect buffer > approach doesn't have. =C2=A0Can someone explain why? Hi Dave, I guess you mean the complexity of MuMaMo, which is a part of nXhtml? nXhtml contains much more. I you have asked some years ago about the indirect buffer thing I could have answered it quickly, but I have forgotten all details about why I abondoned that approach. (It was the first approach I tried.) I am not sure whether to use indirect buffers for just fontification is useful. It does create problems for other elisp code since they might be interested in the actual buffer used. Please notice that some minor modes for example work for a whole buffer and some just within a major mode. So some buffer local variables should be preserved across chunks while others should not. (That problem is quite hard to solve with the current limitations of Emacs though. I have made some suggestions (in private messages) for how to solve it but they require low level changes in Emacs and it is quite hard to figure out exactly what is needed.) I really think some simplifications can be made to mumamo.el, but maybe not as much as one might expect without looking closer at the problems it tries to solve. Some of the complexity comes from my bad understanding of complex parts of Emacs from the beginning so there are some left-over code. It should of course be removed later. The code in mumamo.el is not always pretty and should be simplified in many cases. It is however hard to do since complicated cases easily breaks. I have tried to write some unit tests to simplify the rewriting work. On the other hand most of the complexity comes from the problems that mumamo.el tries to solve. Caching of chunk information and state information is for example essential. You have a comment in multi-mode.el that it would be hard to implement chunks in chunks if chunk information was cached. It is rather the opposite since you have to search the file from the beginning to get chunks right and that is especially important for chunks in chunks. I did not realize the full impact of this from the beginning and I have had to rewrite much of the chunk dividing code because of this. (And there is still unnecessary complexity from my rather worthless attempts trying to make chunk dividing stable without always finding them from the start of the file.) Looking at the bug database in Launchpad for nXhtml (and also the old bugs stored on EmacsWiki) will perhaps make it more clear what the complexity in mumamo.el is about. I have tried to avoid discussing the complexities with multi major modes on Emacs devel since it would take too much time and space. I have tried to do that in some private messages instead. If you are interested I could send you some of my suggestions. I would very much prefer merging different approaches to multi major modes. It is actually very complex (though on the surface it does not seem so). Having several approaches will waste a lot of time. On the other hand forgetting good ideas will also do that. Suggestions for simplifications of mumamo.el are very welcome. > Doing this sort of thing properly really needs support from Emacs, which > was originally meant to be added as necessary. Yes, but it is hard to find out what support is needed without actually trying to solve the problems first.