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 update Date: Wed, 23 Sep 2009 07:43:44 -0400 Message-ID: <1253706224.10118.120.camel@projectile.siege-engine.com> References: <874oqv3ggt.fsf@stupidchicken.com> <200909221530.n8MFUCkh017433@godzilla.ics.uci.edu> <878wg63ssh.fsf@mail.jurta.org> <87k4zqq7x0.fsf@lola.goethe.zz> 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 1253707141 7878 80.91.229.12 (23 Sep 2009 11:59:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Sep 2009 11:59:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 23 13:58:54 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 1MqQUn-0002pK-RQ for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2009 13:58:54 +0200 Original-Received: from localhost ([127.0.0.1]:50875 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqQUn-00040x-Bq for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2009 07:58:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqQGV-0003QY-7E for emacs-devel@gnu.org; Wed, 23 Sep 2009 07:44:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqQGT-0003Pq-ES for emacs-devel@gnu.org; Wed, 23 Sep 2009 07:44:06 -0400 Original-Received: from [199.232.76.173] (port=38040 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqQGS-0003Pd-V0 for emacs-devel@gnu.org; Wed, 23 Sep 2009 07:44:05 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:40236 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 1MqQGS-0006Mm-DA for emacs-devel@gnu.org; Wed, 23 Sep 2009 07:44:04 -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 n8NBhjkY014701; Wed, 23 Sep 2009 07:43:45 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n8NBhjE4014700; Wed, 23 Sep 2009 07:43:45 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: <87k4zqq7x0.fsf@lola.goethe.zz> 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:115546 Archived-At: On Wed, 2009-09-23 at 12:20 +0200, David Kastrup wrote: > Juri Linkov writes: > > >> > 2. I would like to make it possible to enable the different parts of > >> > CEDET using the menu-bar. However, CEDET offers too many knobs to > >> > fit in any of our existing menus, so it probably needs its own > >> > top-level menu. One possibility is to add a "toggle CEDET" menu item > >> > to the Tools menu, which adds or removes a "CEDET" top-level menu. > >> > But this is not "standard menu-bar behavior"-ish. Thoughts? > >> > >> If you do this, please use a more generic name rather than "toggle > >> CEDET", that means nothing for most users... > > > > "Enable IDE"? > > Emacs _is_ an IDE. > > Maybe "IDE mode". I don't know which major modes are affected by this; > it may make sense to offer this just in CC modes depending on that. > I would guess it depends on how CEDET is "integrated" into Emacs. If CEDET is like GNUs, then users would need something like "Enable Project features (CEDET)", similar to "Read Net News (Gnus)". If the pieces of CEDET should be infrastructure (which is how I tried to build it), then it is a mish-mash of features. EDE enables detection of "projects", and a "Project" menu. I did my best to make "EDE Global mode" be transparent when not in a project. Perhaps there are some tweaks that could be done so it could be on-by-default/out of the way in the same way that auto-mode-alist is automatic? The Semantic pieces are different since there is more of a hit when you enable parsing of files in idle time, but setting up parsing tables for major modes is also transparent, and has no affect, other than loading misc Semantic files. Perhaps there are tweaks that could be done to allow that also? I would imagine over time major-modes would set these variables up on their own, instead of having Semantic specific features, so the effect would be the same. Then there are the things Semantic can make better, such as imenu, which-func, eldoc (via a different mode), hippie-expand, and commands like "beginning-of-defun". That is more of a toggle, since users would want to choose the old vs new implementation. This is not really "IDE", those are just aspects of an IDE. This goes back to the question of ... should the buffer parsing mechanisms be considered infrastructure, and have them all there for general use. In a lot of ways, having access to the parsing information is a lot like being able to call 'forward-sexp'. There is a pile of useful data just waiting to be used to do cool stuff in a buffer. I think it is way too early to try and call this infrastructure, but it could be described as "Enable Experimental Buffer Analysis" or "New Code Parsing Features" for a release or two while people figure out where it really belongs. Major modes could choose to use Semantic parsing information even if the user doesn't turn on the maintenance infrastructure, the effects will just be local to a single buffer. Eric Eric