Using VIM as the text editor in KDevelop

[Jonathan Gardner]

On Wed, 21 Mar 2001, Daniel Lynes wrote:
> On Tuesday 20 March 2001 11:43, you wrote:
> 
> > Is there a way to use VIM inside of the IDE instead of KWrite? Or is this
> > just a bad idea... =)
> 
> No...it's a great idea! :)
> 
> There was discussion about it before...I think it was pre v1.0 KDevelop.  
> However, I don't think it went anywhere, because the developers seemed to 
> indicate it would be too difficult to implement a vi mode, because of the 
> command mode, and atm, afaik, they dont' have any hooks for external editors, 
> and code sync.
> 
> For an example of how a scenario like this might work, take a look at 
> Codewright's MSDev synchronization.  It's kinda crazy.  However, vim works 
> fine with MSDev studio without the need for a sync tool, using the visvim 
> plugin.  I don't think you can use plugins with KDevelop yet, though.
> 
> You could always add your own feature, and submit the patch for it to the 
> project, however.
> 
1) I am new to linux. I think I am on month 2, so I have very little experience
with stuff.

2) I have no idea how KDE or X-Windows works, beyond just a superficial
knowledge of what it does. All I know is that I took a look at the structure of
the classes and I was so happy that it wasn't as crappy as MFC. I *am*
interested in learning the KDE API, but right now, I am more interested in
learning how to get big projects to compile on Linux easily. I am a Visual C++
addict, and it is a difficult habit to break.

3) I know too much about windows API, and I spent too much time programming on
that joke-of-an-OS, so I do know how to program, just not for a real OS or a
well-built API.

Now here's the thing... KDevelop is great, but I thought one of the strengths
of Unix/Linux was that you had a whole bunch of little tools you can join
together to do your work. Things like sort, grep, head, tail, spell and such
make life extremely easy for text editing, and things like make, gdb, and g++
make programming all the easier. 

Visvim does allow you to use the power of vim in VC++, but it is a very poor
solution to a poorer development environment on a poorer OS. For instance, you
have to turn it off for debugging. This is not visvim's fault, it is VC++'s
poor implementation of a good idea.

Another cheap trick is changing the keybindings in KDevelop to match vim. This
is just wrong, it's too much work, and you'll always be playing catch-up to
vim. Besides, what if someone were to want to use joe key bindings instead of
vim, and then another guy wants emacs key bindings. It will take a lot of work
to keep things going properly, and if we want to emulate emacs, we have to
become emacs. KDEmacs? I don't think so. Just the thought makes me sick. &p

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.

All of this will of course take a lot of thought, but I think the pay-off will
be trememndous. (not to mention, it will make KDE truly the best environment to
work in forever).

Does this all make sense? Or am I crazy?

 -- 
Jonathan Gardner
gardner at sounddomain.com
(425)820-2244 x123


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