From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: CEDET merge Date: Sat, 03 Oct 2009 22:30:54 -0400 Message-ID: <1254623454.6961.75.camel@projectile.siege-engine.com> References: <87hbun9jbs.fsf@stupidchicken.com> <1254397096.16450.84.camel@projectile.siege-engine.com> <87my48i6ge.fsf@stupidchicken.com> <1254601878.6961.66.camel@projectile.siege-engine.com> <87ab08gcg7.fsf@stupidchicken.com> Reply-To: eric@siege-engine.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1254623473 5005 80.91.229.12 (4 Oct 2009 02:31:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2009 02:31:13 +0000 (UTC) Cc: Sascha Wilde , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 04 04:31: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 1MuGsI-0006ZT-DJ for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2009 04:31:02 +0200 Original-Received: from localhost ([127.0.0.1]:32851 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MuGsH-0000VV-Tt for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2009 22:31:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MuGsB-0000VN-9e for emacs-devel@gnu.org; Sat, 03 Oct 2009 22:30:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MuGs9-0000VA-T7 for emacs-devel@gnu.org; Sat, 03 Oct 2009 22:30:54 -0400 Original-Received: from [199.232.76.173] (port=43128 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MuGs9-0000V7-OP for emacs-devel@gnu.org; Sat, 03 Oct 2009 22:30:53 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:39486 helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MuGs9-0001B4-BH for emacs-devel@gnu.org; Sat, 03 Oct 2009 22:30:53 -0400 Original-Received: from projectile.siege-engine.com (localhost [127.0.0.1]) by projectile.siege-engine.com (8.14.3/8.14.3/Debian-6) with ESMTP id n942Utr9010177; Sat, 3 Oct 2009 22:30:55 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n942Us4I010176; Sat, 3 Oct 2009 22:30:54 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: <87ab08gcg7.fsf@stupidchicken.com> X-Mailer: Evolution 2.26.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:115890 Archived-At: On Sat, 2009-10-03 at 21:44 -0400, Chong Yidong wrote: > "Eric M. Ludlam" writes: > > >> Building in EDE should now work---provided Semantic is enabled from the > >> start. We still need to provide a way for SRecode to call Semantic to > >> parse the template buffer, when Semantic is not currently enabled (this > >> functionality will be useful for other parts of Emacs too). > > > > Semantic can parse files even if all the other related utilities are > > never enabled. As long as srecode-template-mode sets up the parser info > > itself, and not in the new "semantic-mode", then it can use the Semantic > > API to parse buffers during template compilation without interfering > > with someones desire to not enable Semantic parsing and utilities in > > other files, like C++ mode. > > How about this: > > In the Emacs-integrated version of Semantic, we semantic-new-buffer-fcn > so that it runs the mode-dependent parser setup functions before doing > anything else. This is as opposed to running the parser setup functions > from the mode-hooks, as your upstream code does, or in the body of > semantic-mode, as the Emacs version currently does. So, when srecode > calls semantic-new-buffer-fcn, the right setup will take place. > > What do you think? I think I have failed to understand the above. Does the Emacs integrated CEDET no longer use mode-local to call semantic-new-buffer-fcn? That could be good news. The hooks available in Emacs to detect a change in major mode for mode-local.el have been challenging to get right, and I think they can still sometimes not work right. I did fail to explain in my paragraph above that mode-local.el would need to be active for any files to be parse-able. I was referring to semanticdb, and semantic-idle features do not need to be enabled for SRecode to be able to parse/compile template files. As you point out, the semantic-new-buffer-fcn does need to run, and the mode-local settings need to be active for semantic to parse stuff. Is there a desire to have srecode parse/compile template files while leaving mode-local inactive? Does mode-local get activated with semantic-mode? Perhaps I should check out a fresh copy of Emacs to better understand. I've been worried of doing so because I know I'll then need to also figure out how to enable my CEDET distro shadowing the Emacs version, and I don't really want to do that work. Eric