From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: C Mode: acceleration in brace deserts. Date: Fri, 4 Dec 2009 20:03:56 +0100 Message-ID: References: <20091203162129.GA1942@muc.de> <20091203165937.GB1942@muc.de> <20091203193918.GC1942@muc.de> <20091204135444.GC1456@muc.de> 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 1259953475 19965 80.91.229.12 (4 Dec 2009 19:04:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Dec 2009 19:04:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 04 20:04:27 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 1NGdS7-0002hI-BJ for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2009 20:04:27 +0100 Original-Received: from localhost ([127.0.0.1]:54039 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGdS6-0004Bw-JB for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2009 14:04:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NGdS1-0004Bj-I1 for emacs-devel@gnu.org; Fri, 04 Dec 2009 14:04:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NGdRx-0004B9-L3 for emacs-devel@gnu.org; Fri, 04 Dec 2009 14:04:21 -0500 Original-Received: from [199.232.76.173] (port=53822 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGdRx-0004B6-GD for emacs-devel@gnu.org; Fri, 04 Dec 2009 14:04:17 -0500 Original-Received: from mail-yx0-f191.google.com ([209.85.210.191]:43986) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NGdRx-0000xk-36 for emacs-devel@gnu.org; Fri, 04 Dec 2009 14:04:17 -0500 Original-Received: by yxe29 with SMTP id 29so6857495yxe.14 for ; Fri, 04 Dec 2009 11:04:16 -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=z6hjbbL76hYhF8Hl7ePqKwCd6ljWzL3GYMRNj6BBIzg=; b=PNCQZ/q3Fp1Ufi+ia5mYGKugGATOAPve9PtTC1BJfpbGcrx7L5Z6ekjClLMq/cswNN /xyI6+LUU9/rnIl632w25Br1425LvOduLoC7K3dPvuHY6TAbbJP82gmBE3oiveTs938e TCIlVGzin96/Loy0YlAOOId/35i6amQkvm5Nw= 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=QFb+psM4IktCaCcv3JjrvcdurBc8jNhp7ihWpb1N2rU2p9QLkPuDvkXmUPHrgEO99o LN8Wjq9y7e4aAa1UNXEueqzYVCfLlcsEjlDldbuPXSXn684O7wmF1Zi/kgajyRM2+29I m3nb9MiOisZUc0Qb2Wls7vbr0HnKEWk/XghXE= Original-Received: by 10.101.111.20 with SMTP id o20mr4533566anm.185.1259953456193; Fri, 04 Dec 2009 11:04:16 -0800 (PST) In-Reply-To: <20091204135444.GC1456@muc.de> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:118267 Archived-At: On Fri, Dec 4, 2009 at 2:54 PM, Alan Mackenzie wrote: > 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 alre= ady >> >> named. =C2=A0I don't honestly see a way MuMaMo could disturb this sta= te by >> >> accident. > >> > Thanks. Mumamo needs to know because it switches major mode and that >> > normally kills buffer local variables. > > OK. =C2=A0But 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? Several. Some of them are trivial changes that should go into Emacs core like put (put var 'permanent-local t) on major mode independent variables, for example those on editor emulation minor modes. (Those are no-doubts, but may need a bit of works for turning off these modes.) Others are non-trivial trying to fill semantic gaps in variable locality. (Local in major mode, local in chunk etc.) I am unsure which ones I have implemented at the momented. MuMaMo has been much of a testing adventure. >> 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. =C2=A0MuMaMo (or something like it) should go to the core of Emacs. = =C2=A0It > could enable a gross simplification of CC Mode if there were to be some > automatic switchover to "C preprocessor mode". =C2=A0I 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. =C2=A0Such an island could have its = own > syntax table, keymaps and (even) major mode. Yes. This is what MuMaMo is about of course. (Even though it started out with more special cases and much of it is not thought out yet.) > There would, of course, be > numerous details to sort out. =C2=A0Given 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. =C2=A0Sorry. > >> 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? For parsers: No. I thought about it, but come to the conclusion that the only reasonable approach is changing the low level buffer reading primitives. Too much is otherwise difficult to implement in the parsers. At least that is what I believe. I could implement structures in MuMaMo that are lists of buffer chunks in special modes (I started to do that), but it have to be accessed at low level parts of the code and that essentially means that code similar to what I suggested needs to partly written in every parser (or in the low level reading primitives). Without the low level changes also all the old parsers have to be rewritten= . >> 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. =C2=A0;-) =C2=A0It's a pity prog= ramming > 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. =C2=A0This >> 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). >