KDevelop editor interfaces - ups

[Richard Dale]

On Thu, 26 Apr 2001, Matthias Hoelzer-Kluepfel wrote:
> On Thu, 26 Apr 2001, Richard Dale wrote:
> > The current framework is already proving its worth. For instance, I tried the
> > code reformat option last night - it works great on java, and just adds a
> > single menu item to do something useful. And you can set up the plugins you
> > want enabled quite easily with Mathias's option setting plugin. The java
> > jdb debugger will fit in quite nicely when it's done, and be able to run
> > concurrently with the gdb frontend. Both debuggers are optional and just add
> > the menu items they need, and so on...
> these things are not as independent as they seem. The part
> architecture is very good, but as an author of a part, you
> need access to some other parts of the system. For example,
> the reformat part I wrote needs access to the text currently
> in the editor. I solved this by looking up the editor part and
> casting it around to some class I just happened to know to be
> the one use by kdevelop. But the right thing would be to have
> a standardized interface to access this text, and that is what
> part of all this fuss is about. It is not esoteric, it is
> about providing a clean interface so the parts can be as
> powerfull as possible. Believe me, I want to write
> (non-editor!) parts, not interfaces :)
I think you have two goals here; one to add better interfaces to the existing
single editor implementation to get 'the currently selected text', 'the current
file', 'all project header files' etc for scripting. But there is a second goal,
which is to make these interfaces so complete, that you can just slot in another
editor part with a different UI paradigm, and it will all 'just work'. I agree
with the first goal, but I'm not sure that the second one is achievable (I have
no problem with being proved wrong on that).

If 'adding extra editor support' means just adding the keybindings from the
original editor, to a single standard part (Kate/Kwrite), then that is
straightforward and achievable. I think I get suspicious when I read ideas
about the editor part doing its own window management - KDevelop should be
doing that, it is the application in charge. Are we writing an editor which
happens to be an IDE, or and IDE which is trying to be an editor. 

> > The number of people who would move to KDevelop 3.0 because of emacs or vi
> > support is much smaller, compared with the numbers you can get by doing, say,
> > customised java or python programming environments. I would like the idea to
> > be to try and make KDE programming easier for the average programmer, so we pull
> > more programmers away from lesser apis :-). But too much emphasis on bells
> > and whistles for the real programming wizards (ie emacs users) won't do that.
> 
> Again, you are correct, but getting an interface right does
> not mean that it will be any harder to use for an average
> user.  Most of the time, it will get easier.
> 
> And about editor fans: I happen to know one experienced
> KDE developer who started to use KDevelop 3.0 after just
> _showing_ him how he could integrate his loved nedit into the
> framework. (I won't talk any more about that. He is following
> this list closely ;)
So what does the guy love about nedit? Is it the keybindings, window
management, or some lisp scripting environment or whatever? What would be the
minimum to make him happy - would adding nedit keybindings to Kate be
sufficient?

The NeXTSTEP Edit app had emacs keybindings - did that mean it
supported emacs - I don't know. It was handy to be able to hop from word to
word without using the mouse, but I wouldn't want to abandon modeless editing
just to do that. Just add it as an option to the existing editor, or Kate if
adopted.

-- Richard

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«