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: Thu, 3 Dec 2009 19:39:18 +0000 Message-ID: <20091203193918.GC1942@muc.de> References: <20091203162129.GA1942@muc.de> <20091203165937.GB1942@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259868853 7919 80.91.229.12 (3 Dec 2009 19:34:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Dec 2009 19:34:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 03 20:34:06 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 1NGHRE-0007UV-SO for ged-emacs-devel@m.gmane.org; Thu, 03 Dec 2009 20:34:05 +0100 Original-Received: from localhost ([127.0.0.1]:36612 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGHRE-0001ig-Du for ged-emacs-devel@m.gmane.org; Thu, 03 Dec 2009 14:34:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NGHR7-0001hr-T7 for emacs-devel@gnu.org; Thu, 03 Dec 2009 14:33:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NGHR3-0001g3-8z for emacs-devel@gnu.org; Thu, 03 Dec 2009 14:33:57 -0500 Original-Received: from [199.232.76.173] (port=47863 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGHR3-0001g0-5D for emacs-devel@gnu.org; Thu, 03 Dec 2009 14:33:53 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:1330 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 1NGHR2-0002e8-Os for emacs-devel@gnu.org; Thu, 03 Dec 2009 14:33:53 -0500 Original-Received: (qmail 56337 invoked by uid 3782); 3 Dec 2009 19:33:50 -0000 Original-Received: from acm.muc.de (pD9E22654.dip.t-dialin.net [217.226.38.84]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 03 Dec 2009 20:33:49 +0100 Original-Received: (qmail 22668 invoked by uid 1000); 3 Dec 2009 19:39:18 -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:118203 Archived-At: Hi, Lennart! On Thu, Dec 03, 2009 at 06:22:02PM +0100, Lennart Borgman wrote: > Hi Alan, > On Thu, Dec 3, 2009 at 5:59 PM, Alan Mackenzie wrote: > > Hi, Lennart! > > On Thu, Dec 03, 2009 at 05:26:57PM +0100, Lennart Borgman wrote: > >> Hi Alan, > >> Can you tell me how the cache [c-parse-state] is implemented so I can > >> support it in MuMaMo? > > Short brusque answer: no - it's ~1300 lines of code, much of it arcane. > I need only a very short answer. I need to know how you store this > data so I do not destroy it when switching major mode in MuMaMo. Sorry, I misunderstood you. I thought you were wanting to copy the algorithm. The state of this cache is held entirely in the variables (all of them buffer local) initialised thusly: (defun c-state-cache-init () (setq c-state-cache nil c-state-cache-good-pos 1 c-state-nonlit-pos-cache nil c-state-nonlit-pos-cache-limit 1 c-state-brace-pair-desert nil c-state-point-min 1 c-state-point-min-lit-type nil c-state-point-min-lit-start nil c-state-min-scan-pos 1 c-state-old-cpp-beg nil c-state-old-cpp-end nil) (c-state-mark-point-min-literal)) , 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. > In the current situation I can only try to do that since the different > major modes may stamp on each other (I need some more Emacs support to > avoid that). But I can try. In some situations it is needed (for > example php may be split up in several parts (which html code between) > where the indentation in the next part should be aligned to that in > the prev part). > If you store it in a buffer local variable I am happy since all I have > to do then is to make that survive major mode switching. If you store > it in text properties I will be a bit more sad. Ah, yes. I use text properties, too. On each C macro, #if, etc., I set a category property on the "#" and one on (usually) the newline that terminates it. I also put category properties on "<" and ">" to mark them as C++ template or Java generic delimiters. Does this cause you problems at all? -- Alan Mackenzie (Nuremberg, Germany).