From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Improving Emacs for writing code Date: Wed, 23 Apr 2008 13:45:23 -0400 Message-ID: References: <87d4ohq48i.fsf@localhorst.mine.nu> <200804222149.m3MLnF7V028656@projectile.siege-engine.com> <200804231500.m3NF0BpH002463@projectile.siege-engine.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1208972866 29948 80.91.229.12 (23 Apr 2008 17:47:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Apr 2008 17:47:46 +0000 (UTC) Cc: david.hansen@gmx.net, emacs-devel@gnu.org To: "Eric M. Ludlam" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 23 19:48:17 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 1Joj2q-0007D9-5z for ged-emacs-devel@m.gmane.org; Wed, 23 Apr 2008 19:46:12 +0200 Original-Received: from localhost ([127.0.0.1]:39652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Joj2A-0003sY-HM for ged-emacs-devel@m.gmane.org; Wed, 23 Apr 2008 13:45:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Joj26-0003sT-3R for emacs-devel@gnu.org; Wed, 23 Apr 2008 13:45:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Joj24-0003s4-GN for emacs-devel@gnu.org; Wed, 23 Apr 2008 13:45:25 -0400 Original-Received: from [199.232.76.173] (port=50728 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Joj24-0003s0-8O for emacs-devel@gnu.org; Wed, 23 Apr 2008 13:45:24 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182] helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Joj23-0003Cv-Qu for emacs-devel@gnu.org; Wed, 23 Apr 2008 13:45:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAD8SD0hFxIud/2dsb2JhbACBUqwB X-IronPort-AV: E=Sophos;i="4.25,700,1199682000"; d="scan'208";a="18953880" Original-Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 23 Apr 2008 13:45:23 -0400 Original-Received: from pastel.home ([69.196.139.157]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id DVQ23823; Wed, 23 Apr 2008 13:45:23 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 1A9C98064; Wed, 23 Apr 2008 13:45:23 -0400 (EDT) In-Reply-To: <200804231500.m3NF0BpH002463@projectile.siege-engine.com> (Eric M. Ludlam's message of "Wed, 23 Apr 2008 11:00:11 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:95851 Archived-At: >> 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. IIUC this is code similar to what sets up font-lock-defaults or imenu-generic-expression, right? I.e. it is conceptually part of the major mode rather than of CEDET. > * A change-mode hook (and a couple other hooks) enables "semantic" on > any buffer with the right variables set up. I.e. this is like (define-globalized-minor-mode global-semantic-mode semantic-mode (lambda () (if vars are set up (semantic-mode 1)))) ? > * Any tool that requires semantic can automatically enable itself via > the semantic init hook I do not understand this: do you mean that a tool can call (semantic-mode 1), or that a tool can register itself so that whenever semantic-mode is ON, then that tool is activated as well? I'll assume you mean the latter. > 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. So IIUC semantic-mode does not in itself affect the behavior, but because of how features on top of Semantic register themselves in semantic-init-hook, the mere fact of activating semantic-mode ends up activating a lot more. I guess that's fine for now. All we really need is a way to only enable semantic (and accompagnying features) in some modes. E.g. the user can do (global-semantic-mode 1) to get CEDET everywhere, or just: (add-hook 'java-mode-hook (lambda () (semantic-mode 1))) to only get it in in Java mode. Would that be difficult? It seems like you're saying it wouldn't. > 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. Sounds good to me, Stefan