From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: CEDET branch Date: Fri, 11 Sep 2009 12:41:18 +0200 Message-ID: References: <871vmgyhy2.fsf@stupidchicken.com> <8763bquvfh.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1252668831 24038 80.91.229.12 (11 Sep 2009 11:33:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Sep 2009 11:33:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 11 13:33:43 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 1Mm4Nq-0001yi-P3 for ged-emacs-devel@m.gmane.org; Fri, 11 Sep 2009 13:33:43 +0200 Original-Received: from localhost ([127.0.0.1]:34480 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mm4Nq-0003mO-2N for ged-emacs-devel@m.gmane.org; Fri, 11 Sep 2009 07:33:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mm3ZH-0004k3-Di for emacs-devel@gnu.org; Fri, 11 Sep 2009 06:41:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mm3ZE-0004hu-T2 for emacs-devel@gnu.org; Fri, 11 Sep 2009 06:41:25 -0400 Original-Received: from [199.232.76.173] (port=39276 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mm3ZE-0004hg-KZ for emacs-devel@gnu.org; Fri, 11 Sep 2009 06:41:24 -0400 Original-Received: from m61s02.vlinux.de ([83.151.21.164]:55002) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mm3ZE-0007ka-44 for emacs-devel@gnu.org; Fri, 11 Sep 2009 06:41:24 -0400 Original-Received: from kafka.physik3.gwdg.de ([134.76.92.48] helo=kafka) by m61s02.vlinux.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Mm3ZA-0002Cw-6T; Fri, 11 Sep 2009 12:41:20 +0200 In-Reply-To: <8763bquvfh.fsf@stupidchicken.com> (Chong Yidong's message of "Thu, 10 Sep 2009 21:22:42 -0400") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux) 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:115188 Archived-At: Chong Yidong writes: > I wonder, though, whether the merged version of CEDET should provide a > different method for activating CEDET. The out-of-tree version requires > you to put something like > > (setq semantic-load-turn-useful-things-on t) > (require 'cedet) > > in your init file, but a package that is included with Emacs should not > have to be loaded this way. Rather, there should be a command (or set > of commands) that are autoloaded (in the global Emacs loaddefs.el), and > calling the command should load the package. The problem was always that CEDET provides a bunch of different features. If you activate them all, people would complain that it is 'too much', and if you just activate the bare minimum, people would wonder why certain stuff just doesn't work. That's why in upstream there's semantic-load.el, which has several functions to set up CEDET in various different ways, from the bare minimum to absolutely everything. I guess we would have to find a compromise for which features should be activated by default. Eric has surely some ideas regarding this issue. >> * I guess most of the search macros in semantic/find.el will need >> autoloads, most notably the ones under "Top level searches" and >> probably also the ones under "Deep searches". At the moment, I get an >> error that `semantic-find-tags-by-class' isn't defined. > > The semantic-find-tags-by-class macro should be byte-compiled in-place > by any file that requires it. Can you provide a recipe? I guess a (eval-when-compile (require 'semantic/find)) in semantic/analyze/fcn.el should do the trick? I also noticed another error due to removed autoloads: 'semantic-tag-write-list-slot-value' isn't defined when the database is saved upon exiting Emacs. An eval-when-compile won't work here, since this is actually a slot value which is called from eieio. So I guess it either needs an autoload, or 'semantic/tag-write' is required in semantic/db-file.el ? Regards, David