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 12:03:27 +0100 Message-ID: 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1259924716 20528 80.91.229.12 (4 Dec 2009 11:05:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Dec 2009 11:05:16 +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 12:05:09 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 1NGVyG-00069Y-E6 for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2009 12:05:08 +0100 Original-Received: from localhost ([127.0.0.1]:42728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGVyG-0000BJ-6v for ged-emacs-devel@m.gmane.org; Fri, 04 Dec 2009 06:05:08 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NGVx8-00085Z-3G for emacs-devel@gnu.org; Fri, 04 Dec 2009 06:03:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NGVx2-00081G-F1 for emacs-devel@gnu.org; Fri, 04 Dec 2009 06:03:56 -0500 Original-Received: from [199.232.76.173] (port=35402 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGVx2-00080z-0L for emacs-devel@gnu.org; Fri, 04 Dec 2009 06:03:52 -0500 Original-Received: from mail-gx0-f224.google.com ([209.85.217.224]:43039) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NGVx1-0002Rf-GK for emacs-devel@gnu.org; Fri, 04 Dec 2009 06:03:51 -0500 Original-Received: by gxk24 with SMTP id 24so1579866gxk.6 for ; Fri, 04 Dec 2009 03:03:51 -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=dXsD08Vj2z2KUuHCkoJdE9bXLazes/r10XwgHKgyZVA=; b=wmCSfEiXxWWtLtV6liSxAo8wc0+aNY/JyjMbBDLcbaLS+Ghw1OsB441sPwvFazsnku oYAfqe1nDQeG1h7Eg/JhcaCc2g5gIfXf3+os2cH67LqN3kAwEOCowU2BQ2+cYLlehooG 03IC4H7G1GTHohkkPLY/wGd2WSsCHqHKHBtTE= 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=Gw4f3dNh4u7FPNztO0TUazEzT6v6IrXQvE3lBAwry7nxYQDNsh6UEHKHfcYe5e7nIQ LNG4al4h5zsgXgDjGffLMSLHYUkq6pn3+3EJCT67eglg+1s6h9NbiqfRHfl7vLnXCJNJ +Hw0GlYPCD8NfA6P31euvODVtxjjZgw5E29mw= Original-Received: by 10.100.56.12 with SMTP id e12mr3529567ana.162.1259924627095; Fri, 04 Dec 2009 03:03:47 -0800 (PST) In-Reply-To: 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:118245 Archived-At: On Fri, Dec 4, 2009 at 11:34 AM, Lennart Borgman wrote: > Hi again Alan, > > On Thu, Dec 3, 2009 at 8:57 PM, Lennart Borgman > wrote: >> Hi Alan, >> >> On Thu, Dec 3, 2009 at 8:39 PM, Alan Mackenzie wrote: >>> Hi, Lennart! >>> >>> The state of this cache is held entirely in the variables (all of them >>> buffer local) initialised thusly: >>> >>> (defun c-state-cache-init () >>> =C2=A0(setq c-state-cache nil >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-cache-good-pos 1 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-nonlit-pos-cache nil >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-nonlit-pos-cache-limit 1 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-brace-pair-desert nil >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-point-min 1 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-point-min-lit-type nil >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-point-min-lit-start nil >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-min-scan-pos 1 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-old-cpp-beg nil >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0c-state-old-cpp-end nil) >>> =C2=A0(c-state-mark-point-min-literal)) >>> >>> , where `c-state-mark-point-min-literal' merely sets 3 variables alread= y >>> named. =C2=A0I 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. > > > 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. > > 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. > > 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. > > 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. 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. > > > 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. Just a question I forgot: Why are you not using syntax-ppss here? Are you not looking for the same thing (ie inside comment or string). If you did it that way then it would already be supported by MuMaMo.