[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs learning curve
Eric M. Ludlam
Re: Emacs learning curve
Tue, 03 Aug 2010 18:07:03 -0400
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre
On 08/02/2010 03:53 PM, address@hidden wrote:
Lennart Borgman<address@hidden> writes:
On Mon, Aug 2, 2010 at 8:39 PM, Tom<address@hidden> 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:
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
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
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.
Re: Emacs learning curve, Stephen J. Turnbull, 2010/08/02
Re: Emacs learning curve, Andy Wingo, 2010/08/03
Re: Emacs learning curve, Ted Zlatanov, 2010/08/02
RE: Emacs learning curve, grischka, 2010/08/02
Re: Emacs learning curve, Walter Alejandro Iglesias, 2010/08/04