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

[Alexander Dymo]

On Thursday 26 January 2006 21:27, David Faure wrote:
> 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.
I see. We'd need to add scripting language intefrace for our parser then.

> 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.
Ok, this is "make member" feature we have in 3.x. It's implemented in
c++ and compiled in. We'd probably have to write it in scripting language
to make it customizable.

> multi-file grep (someone said it doesn't work in xemacs? I just press F2...
> needs the "igrep" package)
This is probably our "find in files" feature.

> jump-to-next-error after compiling
<F4> in KDevelop.

> one-key for "make", but another key for "make thisfile.lo"
We also have two menus for that.

> the emacs stuff also does some auto code formatting, like inserting a space
> after I type '(' etc.
Ok, another thing to implement (maybe in kate?).

> 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.) -
We have sort of new class templates but they're pretty limited atm.
As for loops and other things we have abbreviations.

> 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.
Sounds like a cool feature to implement!