Re: Emacs learning curve

[David Kastrup]

"Eric M. Ludlam" <address@hidden> writes:

[...]

In a rare bout of top posting with fullquote behind, may I kindly
request that the proper place of the following mail content is as an
introductory chapter

"How does the CEDET universe fit together with other tools"

in the CEDET info file?  Barring that, in its documentation "that is to
become info when the stars are right"?

> 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
>
>

-- 
David Kastrup