From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: C Mode: acceleration in brace deserts. Date: Fri, 4 Dec 2009 13:54:44 +0000 Message-ID: <20091204135444.GC1456@muc.de> References: <20091203162129.GA1942@muc.de> <20091203165937.GB1942@muc.de> <20091203193918.GC1942@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1259934712 20305 80.91.229.12 (4 Dec 2009 13:51:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Dec 2009 13:51:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 04 14:51:45 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NGYZU-0004ID-3I for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2009 14:51:44 +0100 Original-Received: from localhost ([127.0.0.1]:38885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGYZT-0006H6-E2 for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2009 08:51:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NGYXI-0004Sw-Bu for emacs-devel@gnu.org; Fri, 04 Dec 2009 08:49:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NGYXD-0004Mm-Dy for emacs-devel@gnu.org; Fri, 04 Dec 2009 08:49:27 -0500 Original-Received: from [199.232.76.173] (port=44642 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGYXC-0004Lw-H8 for emacs-devel@gnu.org; Fri, 04 Dec 2009 08:49:22 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:4856 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NGYXB-0003yh-Pn for emacs-devel@gnu.org; Fri, 04 Dec 2009 08:49:22 -0500 Original-Received: (qmail 82488 invoked by uid 3782); 4 Dec 2009 13:49:18 -0000 Original-Received: from acm.muc.de (pD9E5155F.dip.t-dialin.net [217.229.21.95]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Fri, 04 Dec 2009 14:49:17 +0100 Original-Received: (qmail 3452 invoked by uid 1000); 4 Dec 2009 13:54:44 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:118254 Archived-At: Hi again, Lennart! On Fri, Dec 04, 2009 at 11:34:11AM +0100, Lennart Borgman wrote: > Hi again Alan, > >> , where `c-state-mark-point-min-literal' merely sets 3 variables already > >> named.  I don't honestly see a way MuMaMo could disturb this state by > >> accident. > > Thanks. Mumamo needs to know because it switches major mode and that > > normally kills buffer local variables. OK. But the buffer local variables c-parse-state and c-parse-state-good-pos have existed since shortly after 4004 BC anyway. Does MuMaMo have a list of such variables it handles specially? > I have a bit trouble with this. I believe there is a simple solution, > but it requires some low level changes to Emacs. Your changes here > illustrates very well why such a change may be desireable to support > mult major modes. Yes. MuMaMo (or something like it) should go to the core of Emacs. It could enable a gross simplification of CC Mode if there were to be some automatic switchover to "C preprocessor mode". I think there should be a special type of overlay ("extent" in XEmacs) which is a "syntactic island" to the syntax routines, and possibly (say, by binding some variable to non-nil) for movement commands too, i.e. these routines would "simply" jump over the island. Such an island could have its own syntax table, keymaps and (even) major mode. There would, of course, be numerous details to sort out. Given how common mixed modes are (C preprocessor stuff, "literate programming", here documents in shell scripts, all sorts of things embedded in HTML pages, ....), it's a wonder we don't already have the tools in the Emacs core. > You are parsing the buffer from the beginning to find a state at a > point (this state is here "in literal or not"). This of course breaks > if there are chunks with different major modes in the buffer. Yes. Sorry. > All parsers naturally behave like this (unless they are not > specifically taught about multi major modes and its implementation). > js2, semantic, font-lock are other examples. Is there a set of guidelines anywhere as to how to make a mode MuMaMoable? > I think the easiest cure for this is to let them just see the parts of > the buffers that are in the programming language they know of at the > moment. (This is perhaps not enough but a good start that covers most > possibilities - and can be used for all parsers.) > This must however be implemented on a low level. "Must be implemented" is in the passive. ;-) It's a pity programming in C is such a dreary business. > All C primitives reading the buffer must know about it. It is probably > in most cases straightforward to implement it. A level between the > buffer reading primitives and the buffer content is needed. This > hides the parts that should not be seen. Agreed. > It is probably possible to support your changes in MuMaMo now, but it > is not easy while it will perhaps break easily instead. I have done > something similar to syntax-ppss. I wish we could have the low level > change instead. Me too! -- Alan Mackenzie (Nuremberg, Germany).