kdevelop (Re: Proposal to plan for "Milestone Releases" on the way to KDE4)

[David Faure]

On Thursday 26 January 2006 01:27, Alexander Dymo wrote:
> On Thursday 26 January 2006 01:44, David Faure wrote:
> > I would need kdevelop to have support for emacs-lisp, or to have at least
> > all the features implemented in kdesdk/scripts/kde-emacs/ (good luck!),
> > but the latter would be less flexible for future extensibility...
> Ok, is it essential for you to have support for lisp. Will other languages
> (lua, python, whatever...) fit you? The question is whether it is important
> to have emacs-lisp or to have powerful scriptability for an IDE.

OK, I admit it doesn't have to be lisp, many things could be offered by kdevelop itself,
and the rest could be scriptable using any language.
In particular doing that stuff from kdevelop would allow to use a real C++ parser instead 
of the regexp-based partial parsing done by the lisp code, which often hits its own limits.

> > For the emacs-lisp support, I know that it's a huge amount of work - Kalle
> > and I started on that one day, extracting the lisp engine and basic
> > functions out of xemacs, and we got to the point where a katepart could run
> > a few simple scripts, but the code was painful, mainly because kate (and
> > the KTextEditor interface) is line+character oriented, whereas emacs works
> > with linear positions in one buffer... interestingly enough, Scribe also
> > works that way, so maybe someone could update that interfacing based on
> > Qt4's QTextEdit...
> I must admit I've never looked carefully at emacs-lisp stuff. 

kdesdk/scripts/kde-emacs/kde-emacs-bindings.el has a pretty extensive comment
about all the default keybindings there and what they do, but here's a summary below.

> Could you please describe in few words what tasks do you accomplish using lisp?

In addition to what Carsten Niehaus described [which is for vim, but most of that
was inspired by kde-emacs anyway, so it's the same features; )],

agulbra-make-member: after writing the declaration for a method in a .h file, press
a key and you get a skeleton implementation in the .cpp file, with default values
removed, virtual removed, etc. etc.

multi-file grep (someone said it doesn't work in xemacs? I just press F2... needs the "igrep" package)

jump-to-next-error after compiling

one-key for "make", but another key for "make thisfile.lo"

one key for switching between .h and .cpp, but another one for actually switching
to the same method in the other file - although I like what I just read about kdevelop
simply showing both in a split view instead, assuming there is a shortcut for
jumping between those two. But well, sometimes you need the buffer to
fill the screen instead of half of it ;)

the emacs stuff also does some auto code formatting, like inserting a space after I type '(' etc.

But there are also things coming from the kdab setup (available on the kdab website iirc), like
- templates (e.g. for new qt class, for all sorts of iterator-based loops, etc.)
- wide-edit (do a multi-file grep, and then the buffer with the results is *editable*. When 
saving that buffer, the changes are propagated back to those files. This is really a time-saving
feature for refactorings in an editor which doesn't support refactoring.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).