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[2]: Improving Emacs for writing code Date: Wed, 23 Apr 2008 11:00:11 -0400 Message-ID: <200804231500.m3NF0BpH002463@projectile.siege-engine.com> References: <87d4ohq48i.fsf@localhorst.mine.nu> <200804222149.m3MLnF7V028656@projectile.siege-engine.com> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1208962855 24489 80.91.229.12 (23 Apr 2008 15:00:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Apr 2008 15:00:55 +0000 (UTC) Cc: david.hansen@gmx.net, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 23 17:01:26 2008 connect(): Connection refused 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 1JogT4-0006cM-D0 for ged-emacs-devel@m.gmane.org; Wed, 23 Apr 2008 17:01:06 +0200 Original-Received: from localhost ([127.0.0.1]:52538 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JogSO-0000lY-Hj for ged-emacs-devel@m.gmane.org; Wed, 23 Apr 2008 11:00:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JogSI-0000jx-5Y for emacs-devel@gnu.org; Wed, 23 Apr 2008 11:00:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JogSF-0000iY-KI for emacs-devel@gnu.org; Wed, 23 Apr 2008 11:00:16 -0400 Original-Received: from [199.232.76.173] (port=57533 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JogSE-0000i2-Te for emacs-devel@gnu.org; Wed, 23 Apr 2008 11:00:14 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10] 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 1JogSE-0006OI-A2 for emacs-devel@gnu.org; Wed, 23 Apr 2008 11:00:14 -0400 Original-Received: from projectile.siege-engine.com (localhost.localdomain [127.0.0.1]) by projectile.siege-engine.com (8.12.8/8.12.8) with ESMTP id m3NF0BZi002467; Wed, 23 Apr 2008 11:00:12 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.12.8/8.12.8/Submit) id m3NF0BpH002463; Wed, 23 Apr 2008 11:00:11 -0400 In-reply-to: (message from Stefan Monnier on Tue, 22 Apr 2008 21:33:00 -0400) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:95840 Archived-At: >>> Stefan Monnier seems to think that: [ ... ] >> There are a few sub-tools in CEDET that probably need care when >> merging. When I needed convenience functions in CEDET for a specific >> tool, I usually focused on making them generically useful. As such, >> each such tool should probably be examined to see if that is a feature >> Emacs wants. One item that comes to mind is the mode-local variables >> and functions that has been discussed here at least twice. > >Do these use advices or similar redefinitions? If not, it shouldn't be >a problem. There is advice in CEDET, though not much. Most advice deals with `describe-function' and similar help routines that are not inherently extensible. Other advice is tied to some minor-mode or other. >> Right now, CEDET installs assuming you want to use it. This may not >> be the case in core Emacs. Making the features accessible has been a >> struggle. Stefan touched on one such issue in his post. I have no >> good answers. > >The first step is to make sure that when installing CEDET in Emacs we >get 2 things: >1 - CEDET is easy to enable. >2 - CEDET doesn't affect anyone who doesn't enable it. >That is a strict necessity before we can install it. The second step is: >- Make it possible to disable CEDET after enabling it. >- Make it possible to enable CEDET in some buffers without it affecting > all others. >These are very important as well, tho it might be OK to live without >them at first, as long as there's a clear commitment to address them. Everything in CEDET that changes or augments a behavior is activated by hooks, or something in a user's .emacs file. The CEDET build system automatically adds (add-hook ...) type items into the loaddefs file which is what you had encountered. The goal of the CEDET install is to minimize the amount of hacking around users have to do to get the system up and running. The semantic parser and tools work like this: * A mode hook sets up variables about how to do parsing. * A change-mode hook (and a couple other hooks) enables "semantic" on any buffer with the right variables set up. * Any tool that requires semantic can automatically enable itself via the semantic init hook The default right now is that all mode hooks are enabled by default. The Semantic setup from the mode-hook itself won't change any behavior. It is the tools that enable themselves via the semantic init hook that change behavior, and those tools are turned on via a `global-whatever-mode' type function which must be put into a .emacs file. If you want some tools on in C mode but not in Emacs Lisp, you would not use `global-whatever-mode', but instead create a semantic init hook that turns some minor-mode on with `whatever-mode' conditionally. You might be able to enable some modes in a mode-hook, but I haven't tried it. Some may depend on semantic initialization completing first. As such, what you are requesting is possible, and follows typical conventions, but just requires more INSTALL explanation. I am hesitant to add such discussion because the current install instruction is short and simple, and discussing all those options would make it much less so. I've batched many modes together into "turn on lots of related things" functions which means all sub modes would need explaining for basic install. I'm open to any changes in this area to make this easier, as long as there continues to be a simple "just make it go" feature. Eric -- Eric Ludlam: eric@siege-engine.com Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net