Using VIM as the text editor in KDevelop

[Roland Krause]

No, No, No,... 

you are obviously not understanding the fundamental principle of KDE. 

KDE is an integrated desktop environment. That means that applications
not only just understand each other somehow but that they are actually
integrated components for each other. 

That is a fundamental difference. Look at the kparts stuff, it makes it
very clear how things should work together. 

Besides: Netscape is dead, your choice is IE or IE, so just say "Lets
forget about that stupid html widget in KDE" that is just like saying
"Lets forget about Linux and use windows". 

I am sorry to sound rude but comments like yours drive me up the wall. 

I dislike emacs just as much as you do, I dont like vim either, the
kwrite guys seem to have given up on kwrite themselves, the kwrite code
in KDevelop is such a mess that one might want to cry... At the same
time some people have begun to write kant which started of as MDI
version of kwrite but is rapidly approaching emacs... again... 

Ok I stop ranting and shut up know... 
Sorry
Roland




--- Jonathan Gardner <gardner at sounddomain.com> wrote:
> 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«


=====
--
Roland Krause
In the garage of life there are mechanics and 
there are drivers. Mechanics wanted!

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

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