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: Emacs learning curve Date: Tue, 03 Aug 2010 18:07:03 -0400 Message-ID: <4C589307.5060106@siege-engine.com> References: <10954D02-E217-49F3-8824-757DA34074AB@gmail.com> <83zkxzakr0.fsf@gnu.org> <83pqyva8ms.fsf@gnu.org> <834ofczxv2.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1280873245 5776 80.91.229.12 (3 Aug 2010 22:07:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Aug 2010 22:07:25 +0000 (UTC) Cc: Tom , Lennart Borgman , emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 04 00:07:23 2010 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.69) (envelope-from ) id 1OgPdm-00057E-SH for ged-emacs-devel@m.gmane.org; Wed, 04 Aug 2010 00:07:19 +0200 Original-Received: from localhost ([127.0.0.1]:42598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgPdm-0000aj-0d for ged-emacs-devel@m.gmane.org; Tue, 03 Aug 2010 18:07:18 -0400 Original-Received: from [140.186.70.92] (port=41689 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgPdd-0000Wp-5x for emacs-devel@gnu.org; Tue, 03 Aug 2010 18:07:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgPdb-0005zw-Kc for emacs-devel@gnu.org; Tue, 03 Aug 2010 18:07:08 -0400 Original-Received: from bird.interbax.net ([75.126.100.114]:39883) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgPdb-0005zl-FT for emacs-devel@gnu.org; Tue, 03 Aug 2010 18:07:07 -0400 Original-Received: (qmail 24403 invoked from network); 3 Aug 2010 17:07:04 -0500 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net (HELO ?192.168.1.201?) (71.184.83.10) by interbax.net with SMTP; 3 Aug 2010 17:07:04 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Windows 98 (1) 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:128206 Archived-At: On 08/02/2010 03:53 PM, joakim@verona.se wrote: > Lennart Borgman writes: > >> On Mon, Aug 2, 2010 at 8:39 PM, Tom wrote: >>> >>> And why not add these by simply reusing the work of others? >>> >>> The most requested and popular features are code >>> completion, refactoring and such. I know CEDET can do some of >>> these, but I wonder if Emacs should harness the effort put into >>> these areas by other development teams. >>> >>> Take a look at the screenshots IdeBridge for example: >>> >>> http://www.emacswiki.org/emacs/IdeBridge> >>> >>> It uses SharpDevelop libraries to provide completion. I know a >>> pure elisp solution would be the best, but given the plethora of >>> languages it's not a realistic goal to provide a comprehensive >>> Elisp backend solution for everything due to limited developer >>> resources. >>> >>> The best approach may be to provide a standard code >>> completion (refactoring, documentation lookup, etc.) frontend in >>> Emacs into which any backend implementation can be >>> plugged. People would write bridge code like in the above example >>> to handle communication between the frontend and the selected >>> backend. There are no licensing issues, because it can work >>> with process communication. >> >> >> I think that CEDET already makes this possible, but Eric can surely >> give a better answer. (Maybe this should be pointed out very clearly >> in Emacs doc, at least as a goal?) > > Just to reiterate, (Eric will surely put it better): > - Cedet is as the name implies "a Collection of Emacs Development Tools" > - One tool is Semantic, which basically is a collection of interfaces > and different implementations of parsers for various languages > - It is possible to implement the semantic interfaces on various > different backends, several such implementations are included in Emacs. > > I worked on a couple of such implementations, and while its not always > super obvious how to do it, I think anyone with a genuine interest in > implementing a new backend to Semantic can do it. In fact, not using the > Cedet interfaces is what would be a waste, its the best shot Emacs has > at implementing these modern ide facilities. As is suggested above, CEDET is a a bunch of interfaces with default back-ends and front ends. It is similar in nature to GUD or the VC stuff, but instead uses different mechanisms to create the abstraction. A large portion of the miscellaneous tools in CEDET use EIEIO to create a series of base classes that define the interface or API that some user interface interacts with. Some examples are: EDE - This defines some basic concepts of what a project and target are. It then implements project styles for Automake, Make, Emacs, Linux, and some others. On top of these classes is global-ede-mode. This defines a menu and some misc keybindings for compilation or whatever. In the context of some external tool like SharpDevelop, Visual Studio, Eclipse or whatever, if it is possible to read those project files EDE can wrap it and the implementation can dispatch back out to that tool to do the project management work. Someone who then learns how to work in one kind of project in Emacs (via keybindings or what-not) will know how to work in another project even if the back-end is totally different. Semantic then uses the EDE interfaces to provide project level configuration of what files to search or what CPP macros exist. SemanticDB - The databases used by Semantic to track tag info which is used for completion is also based on EIEIO classes. The default just saves stuff to disk, but other back-ends, such as the Emacs backend uses Emacs commands to lookup symbols, or the GNU Global backend can query a GNU Global database. The Semantic tools also use mode-local to create an interface boundary. In this case, on a per-mode basis. Thus the C++ support use the parser generator in Semantic to parse the code in a buffer and save off the tags. External parsers can be installed used instead, such as the exuberent ctags parser, so on a per-mode basis, you can configure and use different backends. The completion engine is the same. If there is an alternate implementation for creating a list of possible completions for a particular mode, you can override the right function to provide the output. Any tool that uses Semantic's smart completion engine would then automatically start using the new external tool (such as SharpDevelop) instead. Not yet a part of Emacs, the COGRE UML tool uses the Semantic back end, mode-local override features, and EIEIO to generate code from high-level concepts such as class diagrams. COGRE uses EIEIO, and any kind of connected graph could be created besides the UML implementation. I hope this helps answer questions. I do think that the original poster's desire for a place to put a back-end already exists in the CEDET infrastructure, and if it doesn't do it perfectly for some case, we can certainly tweak the API if needed. Eric