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: Tue, 22 Apr 2008 21:33:00 -0400 Message-ID: References: <87d4ohq48i.fsf@localhorst.mine.nu> <200804222149.m3MLnF7V028656@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 1208914478 10386 80.91.229.12 (23 Apr 2008 01:34:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Apr 2008 01:34:38 +0000 (UTC) Cc: David Hansen , 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 03:35:12 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 1JoTtA-0007cZ-4O for ged-emacs-devel@m.gmane.org; Wed, 23 Apr 2008 03:35:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JoTsU-0000Ex-Eb for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2008 21:34:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JoTr5-0006xT-4R for emacs-devel@gnu.org; Tue, 22 Apr 2008 21:33:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JoTr4-0006vq-8p for emacs-devel@gnu.org; Tue, 22 Apr 2008 21:33:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JoTr3-0006vj-On for emacs-devel@gnu.org; Tue, 22 Apr 2008 21:33:01 -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 1JoTr3-00018G-MM for emacs-devel@gnu.org; Tue, 22 Apr 2008 21:33:01 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4CAPYuDkjO+KGddGdsb2JhbACBUpACASqbKg X-IronPort-AV: E=Sophos;i="4.25,696,1199682000"; d="scan'208";a="18899637" Original-Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 22 Apr 2008 21:33:01 -0400 Original-Received: from pastel.home ([206.248.161.157]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id DFE00801; Tue, 22 Apr 2008 21:33:01 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id BDBBE8066; Tue, 22 Apr 2008 21:33:00 -0400 (EDT) In-Reply-To: <200804222149.m3MLnF7V028656@projectile.siege-engine.com> (Eric M. Ludlam's message of "Tue, 22 Apr 2008 17:49:15 -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:95817 Archived-At: > I would be happy to see CEDET in Emacs. It has always been a goal > of mine, but I also know my long-term vision for CEDET does not always > map onto what others want to see, and picking out only the tasty bits > of CEDET may be hard without using the entire thing. > Here is the good news: > * All paperwork needed for all the contributions should be in order > for core CEDET. Items for which there is no paper work is in a > "contrib" directory to help me keep them separate. Excellent. > * I do my hacking on CEDET in a mostly up-to-date version of Emacs > from CVS, so it should work straight away. > * For the first time in a long long time, I'm happy with the current > state of CEDET and how it works with code-completion. For most folks, > code completion is the only reason to use CEDET. It feels ready. > I've been going through my pre-release checklist lately to get a > release of my own done. Good to hear. > Maintenance issues: > I do not have a blanket release from my employer to provide changes > to Emacs whenever I want, and I cannot get one. I can get a new > time-bound release whenever I want, but it's a pain. An ideal > situation would be one where I can keep hacking CEDET at will, and > provide periodic updates back into Emacs core without having to go > through a merge phase. > Speedbar is in Emacs in a way that requires merging between our CVS > trees. The merges are difficult, which means I don't do them very > often, because I can't really contribute to speedbar in Emacs proper. Yes, it's been problematic. I do think this problem can be significantly reduced on your side by simply regularly merging from the Emacs-CVS tree, so the Emacs-CVS tree may not always be up-to-date with yours, but yours is, so whenever we need to sync the two, the merge has already been done. If you use some of the non-CVS mirrors of Emacs (Arch, Bzr, Hg, Git), the merges can be tracked by the tool, so you can do them "daily" with no hassle (note that those mirrors are only readable, but that's OK for your use). > 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. > 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. > repositories, or provide a way for me to check stuff into a GNU > repository when I'm not actively covered by an employer release, I'd > like to know about it. As long as your own repository has clear information about its relationship with the Emacs-CVS code (I don't mean info for humans, but for tools, in terms of history and ancestry), then I think it's livable. Stefan