Using VIM as the text editor in KDevelop

[Christian Rahn]

Yes, I have to agree to this, don't try to invent THE ABSOLUTE new
editor. There are so many already. And KParts should be able to do this
job. There should be kind of a "regularization" or "systematization" of
the process of "writing a text" or "writing a program" or "writing
html" and of course of just "viewing text" etc. Those are absolutely
different things. And why should the wheel be invented newly for every
next big project? The KDevelop is really cool, but I for myself prefer
using xemacs because it's editing capabilities are more suited for me than
kwrite's (although it got pretty nice meanwhile). A combination of both
would be great, but creating a bitch like Kemacs? No, please don't. It's
already enough for that two [X]emacs' (besides other 'frankensteins'...)!
 The point is: Modularization. Just maybe as pushing kwrite as far as 
possible and make it a KPart, so that every application can profit from
it. And maybe a middle layer, which enables other editors to
participate. I don't think, that the vim-team or the emacs-team are happy
to implemnt some signals/slots or anything for KDE/KDevelop. Next month
the Gnome-people are knocking on their doors, and the CDE-people and then
M$?

regards, CDR

> ...
> So, in my mind, the solution is to kind of limit the scope of KDevelop - let it
> manage your projects, do all the cool stuff like that, but let the actual
> editing tools and document viewing tools reside outside of it, and totally
> independent of it. If we end up writing an API between KDevelop and any editor
> or document viewing tool, why let it work only for KDevelop? Let the whole KDE
> environment use it. Whenever you are browsing, and you want to edit the
> document you are looking at, the browser uses the API to call up your favorite
> text editor and allows you to edit it. Why stop there? Any time you want to
> view a document, we can let the user specify which programs he wants to use to
> view it. The browser in KDE is great, and I totally want to see it come to
> fruition, but it just isn't Netscape (or IE or Opera for that matter).
> 
> Here's what I am talking about:
> 
> 1) an API to allow applications to call up the user's favorite application for
> a certain role. This includes displaying or editing a document, but it can be
> extended in the future. With this, the only applications that will ever need to
> display or edit text are those designed specifically to edit or display a
> document. This is inline with the Unix philosophy of a bunch of little, highly
> specialized tools that combine to do a lot of work together.
> 
> Some things the API will need to include are abilities to insert text into the
> document, do search/replace, and move the cursor, as well as marking text, and
> other basics that all text editors can do. Why? For instance, if we build in a
> function where we automatically create classes for the user, then we need to be
> able to insert text into the document. If we want to jump to a function, we
> need to have that line marked (not the line number, the line! so if it moves,
> it will stay marked) We need search/replace functionality if someone renames a
> function with a special function renaming macro in KDevelop, so that KDevelop
> cna find and replace all instance with that function name. 
> 
> 2) System settings to allow the user to specify which applications he wants to
> use. We should differentiate between viewing and editing a file. For instance,
> I might want to use KWrite to edit HTML, but I want to use Netscape to view it.
> 
> 3) Drivers to interface between the editor and the API. Leaving this up to the
> VIM team, the emacs team, or the joe team is really easy to do, and I am sure
> they will be happy to do it. It shouldn't be too hard to implement these
> drivers for many applications that already exist. Perhaps we can hard-code the
> driver into the application, making it ready to rumble with the API.


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