KVim Reaches Stable Milestone

Thomas Capricelli, Philippe Fremy, and Mickael Marchand are pleased to present the first ever stable version of KVim, finally bringing us "the power of VIM with KDE's friendliness". In case that means nothing to you, VIM stands for Vi IMproved and has become the defacto standard version of Vi on most Linux distributions. Vi is the traditional, ever popular, text editor on UNIX systems which can sometimes be a challenge to new users. As the names imply, VIM adds many powerful improvements over Vi, and KVim wraps the whole thing up in a nice KDE interface. Best of all, KVim offers a KPart for out-of-process embedding in KDE. The KPart can currently embed either of GVim or KVim in Konqueror, but further work is required before proper support for KDevelop, KMail and Kate is available. It also looks like KVim will be integrated into the main VIM source distribution in the future. Great news!

Side note: Interestingly, one of the first articles ever on KDE Dot News concerned the first developer release of KVim. It generated quite a bit excitement at the time, although it seems we jumped the gun on the KDE/XEmacs rumours. :-)

Dot Categories: 


by mark dufour (not verified)

being able to work with vim from within kmail and other kde applications would be like a dream come true for me.. I'd give up kde 3 for this feature (if I had it)

by Triskelios (not verified)

The current CVS of KVim works with KDE 3 (only).

by Kevin (not verified)

Okay, maybe I am just missing something, but how do you use KVim in Konqueror? I have downloaded/compiled/installed the complete KVim package and can use KVim as stand alone without any problems(look great!). But I can find no way to use the KPart in Konqueror. Any instructions would be very much appreciated.


by Richard Moore (not verified)

I'm an emacs user myself so I haven't tried this, but I'd imagine you just need to change the preference order in your file associations. Open up the settings dialog and choose the file associations section, then look for text/plain and see if you've gained a KVim option under the embedding tab.


by Kevin (not verified)

Thanks, but that is just it...I don't have a KVim or a Vim option under the embedded tab, so I am unsure of where to look next.

by jhollett (not verified)

the instructs say after running testVim go to the /kvim/vimpart/kde-version directory and run ./configure, make, make install. the problem is that there is no configure script in that directory. i tried make -f Makefile.cvs, but it errored out. so i'm looking for a little help with this too.

by Moritz Moeller-... (not verified)

It would help if you posted the error messages. Maybe you have an older version of automake and autoconf installed?

Here it worked just fine.

by jhollett (not verified)


slackware 8 distro
*** Concatenating configure tests into acinclude.m4
*** Creating list of subdirectories in subdirs
*** Searching for subdirectories...
*** Retrieving configure tests needed by configure.in
*** Scanning for include statements
autoheader: error: shell error while sourcing /tmp/ah6249/traces.sh
make[1]: *** [cvs] Error 1
make: *** [all] Error 2

i then installed newer automake & autoconf

new automake 1.61 & autoconf 2.53
*** Concatenating configure tests into acinclude.m4
*** Creating list of subdirectories in subdirs
*** Searching for subdirectories...
*** Retrieving configure tests needed by configure.in
*** Scanning for include statements
aclocal.m4:672: error: m4_defn: undefined macro: _m4_divert_diversion
autoconf/lang.m4:173: AC_LANG_RESTORE is expanded from...
aclocal.m4:672: the top level
autoheader: autom4te failed with exit status: 1
at /usr/local/bin/autoheader line 163
make[1]: *** [cvs] Error 1
make: *** [all] Error 2

command: make -f Makefile.cvs

by Kevin (not verified)

Okay, I figured out that the error I was getting when doing the 'make -f Makefile.cvs' was from having an older version of autoconf. After upgrading it worked great, thanks.

One note, in the output from doing the 'make -f Makefile.cvs' with autoconf 2.13 you get the following message:

*** YOU'RE USING AUTOCONF 2.13. We suggest updating.
*** autoconf 2.5x works best for now, we will drop
*** support for autoconf 2.13 soon.

Quickly followed by some errors that halts the make. After tricking the make into getting by these errors, I was then presented with this message:

FATAL ERROR: Autoconf version 2.50 or higher is required for this script

I think it would be a little more useful if the first message just said this to begin with and then halted instead of trying to continue and saying that support will be dropped "soon" as it appears to have already been dropped.

Thanks again for getting kvim going!

by Thomas Capricel... (not verified)

You'll be happy to know that we're working on kvim-6.1, that should be released not so far from now. Featuring a sync with vim-6.1 and lot of bug fixing from the kvim-6.0 release. Also, we've started to talk with the kdevelop people to see how to make the vim part a KTextEditor, stay tuned.
You can come and see us on #freehackers or #kde (on the openproject network)

by jon (not verified)

This is great news. And I am jealous (the very first time) on all ppl who have chosen Vim.

Too bad I hat it like a disease.

I also hate all these amateurish editors being integrated into the UI, something that got invented on WindOwS and just proves how many Linux programmers are converted Windows programmers/users.

Another such stupid Windows-Inheritance is that also in Gnome and KDE the Filemanager handles directories just as they would be documents.

Of course, this does not change my passion with KDE a slightest bit ;-)

So, when do we see KEmacs and its according KPart ?

I still do not understand what this is/was about it.

It shouldn't be so hard to wrap around it, export all the elisp functionality to dcop and have it embedded in KDevelop...


by jd (not verified)

>Another such stupid Windows-Inheritance is that also in Gnome and KDE the Filemanager handles directories just as they would be documents.

I'm kinda curious about what you mean by this. How would you like it to be done?

by Jonathan Brugge (not verified)

I guess he means that there's only one filelist in most filechoosers, where he would like to see a list containing the directories and another one (next to it) with the actual files. Though the current behaviour doesn't hinder me, that seems like a good idea. Though directories are in fact just another file, they differ quite a lot from the user's point of view. I believe the old KDE1 did it this way: at least my KLyX that I still use has a separate dirlisting left of the files.

by hmmm (not verified)

Hey, you know what, I love KDE because it is so fantastically flexible and configurable -- in this case :

Right click in the fileselector window, and you are given the option (amongst others) to have dirs and files separate.

In fact, try right-clicking on all widgets : there is a wealth of config possibilities in all of them !

by jon (not verified)

>Hey, you know what, I love KDE because it is so fantastically flexible and >configurable -- in this case :

Well, it is configurable only on the surface, superficially...

>Right click in the fileselector window, and you are given the option (amongst >others) to have dirs and files separate.
>In fact, try right-clicking on all widgets : there is a wealth of config >possibilities in all of them !

Yes, it is a begniing. Especially the embedded console is a good idea.

But this still is an excuse of a filemanager, not more. It seems to me you never used a 'real' filemanager, you would see how much this is worlds apart.

The only really good filemanager I came acrosson Linux was Worker and MidnightCommander.

The v6 version of DirectoryOpus is (Windows only, commercial) here:
And some screenshots are here:

A screenshot, demonstrating the power of filemanagement on AmigaOS:

No eyecandy, though. Note, that each of the four listers you see here is a normal window, they have been arranged (probably by a keypress) to occupy the screen in this state. Of course all is supported (cut,copy&paste, drag&drop) as well as doing all kind of funny things (all basic tasks like copy,move,rename,link,archive,dearchive) and whatever by the buttons you see. Also note, that the "listers" can be used in icon-mode as well.

I still do not see any way to archive a bunch of files with Konqueror without opening the embedded console or maybe drag&drop into an opened archive.

Oh, and since we are at screenshots and my favourite computer system, have a look at here:


Quite nice for an OS from 1992 ?!

by Sean Russell (not verified)

Directories /are/ files. They're just files with links to other files. In fact, rather than separate out directories, they should be handled like files even more than they are, and files should look a lot more like directories.

Directories should be able to have mime types and associated applications. I'd like to be able to create NeXTSTEP-like .app folders that are executed like applications. Files should have directory attributes; I'd like to create associations between files, so that files can be browsed like directories.

The separation of directories and filesystems is a limited metaphor. BoOS, with its DB-based FS was a step in the right direction, but encountered some engineering problems. A very good example of what filesystems /should/ look like is at http://www.reiserfs.org/whitepaper.html. In the short term, artificially increasing the similarity between file nodes and directory nodes is a good thing to do.

by Uno Engborg (not verified)

You mean that it should be possible to specify drop actions like running
a certain program when a file of a certain mime-type is dropped on a folder?

This would be a very good idea, but this is not somthing that should be handled
by a GUI like KDE. This should be handled at filesystem level. That way we get
no inconsitent behavior if files are moved or copied with other tools or programs
than the filemanager.

by jon (not verified)

>I'm kinda curious about what you mean by this. How would you like it to be >done?

Well, just check it out. Open up Konqueror in Filemanager mode.
The most blatant hint you will get (at least if you use the german locale) is the very first menu, it is named: "document" (or maybe "file" in the english locale.

Now you should get it.

If still not, have a look at the "Edit" menu. You find the Cut,Copy&Paste items there. Typical for a document-application. (I think, however, that a "real" filemanager should have these as well, since it is a good idea, but it should not be the only way to copy/move files besides drag&drop.)

This kind of interface to access directories was invented by Microsoft. It is a good idea onthe one hand, since it adds consistancy to the user interface.

On the other side it is a horrbile idea, since a directory is completly different from a two document like a Word file, spreadsheet or DTP doc.

Also the treeview is not the best way to represent deeply nested directories. As soon as it is deeper than three or four levels you find yourself resizing the tree-panel already. And this just to name one of the many misconcepts in this.

Also, with these programs (IExplorer, Nautilus and Konq) it is difficult to do power-filemanagement, since the windows are designed in a way, that it is impossible to have several open (on a normal reso like 1024x768 or 1280x1024) without cluttering each other, at least in parts (I am talking of more than 3 or four windows here).

Even than, there is simply no way to add user-defined buttons/menus/shortcuts or popups, one of the most important feature of any decent filemanager.

A "real" filemanager has at least two identically set panes next to each other. Even better four (two on each side but breowsable) even better - as many as you like, layouted in a fashion that allows quick and fast access to many such panes (or better name them "listers).

There are some attempts to give Linux a good filemanager.
Krusader, which is too simple.
Gentoo (the filemanager, not the distro ;-)) which is better.
Even better is Worker.

Note, that Worker and Gentoo claim to try to imitate a program they reference as "Dopus". Which is short for "DirectoryOpus" the mother of all Filemanagers (it was introduced on AmigaOS and was fully scriptable and configurable. On AmigaOS, configuration of an app means more than moving floating panesl around and adding another theme, it measn usually tailoring all buttons and menus with commands/scripts the user wants.).

Dopus got even better in V5 (and now on Windows it is reviewed as one killer application onmany sites, it is v6). On Amiga it replaced the whole desktop and offered as many views/listers as one wanted. I would like to see a similare approach (without loosing KDE as desktop) with kparts and whatever.

by ac (not verified)

Try menu Settings -> Load Profile -> Midnight Commander

As a matter of fact, Konqueror is quite customizeable, you can rearrange its windows as you like.

by jon (not verified)

I have commented on that already.

This "MC" mode is not really what I had in mind. You might want to read my previous posts (a few lines up) to see what I am talking about.

Unless you did not see it, please do not suggest Konqueror's MidnightCommander mode.

by Carbon (not verified)

Actually, the first menu is named Location in the English version (at least in 2.2.2). Also, it's important to note that Konqueror is _not_ a file manager. It's a multipurpose app. CC&P is certainly appropriate for a web browser, which Konqueror is, and for many other things that Konqueror does (like PDF viewing, etc, etc). However, I do agree that Konqi's interface is a little contrived at parts. I remember the Konqueror usability study, that had some great ideas that were consequently ignored. Strange, that...

Also, add TkDesk to the list of file managers that are good. Practically everything is scriptable. It doesn't have that multi-pane mode on by default, but you can set that easily enough.

Yeah, it should at least be possible to remove the file manager part and replace it, the same way that you can replace KHTML with Gecko for HTML rendering (though hopefully a little bit more stable :-).

by jon (not verified)

"Actually, the first menu is named Location in the English version (at least in 2.2.2)."

Ah, okay, thanks for reporting this. So I do not fall on my nose in any later "rants" ;-)

"Also, add TkDesk to the list of file managers that are good. Practically everything is scriptable."

That sounds good. I will check it.

"Yeah, it should at least be possible to remove the file manager part and replace it, [...]"

Yes, a new filemanaging KPart would be nice.

by Jim (not verified)

It's a nice idea. But I can't seem to configure it with any color scheme that is even remotely readable. Using gvim for now.

by Stuart Herring (not verified)

Yes, having just tried it, I must admit that I had the same problem.

I use gvim with the default colour scheme, and that's fine for me, but kvim with the default scheme seems to not have the same amount of contrast...the colours are all a little too light, the dark blue colour scheme was the closest to being useable for me, but I prefer a white background.

by Mickael Marchand (not verified)

have you tried the full vim package ? or only the kvim binary ?
(any screenshot i could see to compare your kvim and your gvim ?)


by Stuart Herring (not verified)

I grabbed the latest development version from CVS, and installed using the kvim copy of the vim runtime.

gvim is 6.1 as provided in debian unstable.

It appears that it's no so much that the colours are bad, but the the interpretation of the syntax highlighting is different.

I've posted screenshots on http://www.cumulo-nimbus.com/vim

I verified that default.vim was identical in both gvim and kvim, and I copied the c.vim from the gvim installation to the kvim one, so they were the same too (though they only differed by a couple of lines relating to comments originaly anyway)

You can see that the colour test pages are nearly identical, whereas the c syntax examples are quite different.

Another thing I noticed is that kvim seems to handle fonts weirdly...when you select a font in the font selection dialogue, the one you actually get is different, and I'm unable to get the same font I use in gvim at all....though font issues may be more of a problem with the KDE libraries in general....

by Mickael Marchand (not verified)

thanks a lot for the screenshots, now i know what i have to fix ;)

this is a really 'strange' bug, it will need some investigation
what I can't understand is why the color test is ok whereas the real C syntax highlighting looks different, maybe i forgot something in syntax highlighting in KVim.

Concerning the fonts,
I tried to stay X (and gvim) compatible and keep compatibility with XFLD font names : courier-bitstream-*-*-*-14-r-m-*-*-*
I know think it was an error as QT badly handles these (look qfont.html for more precision about it)
so, soon in CVS (probably monday), you'll have only QT fonts supported (and better supported), then any setting saved in your ~/.gvimrc will have to be rewritten like : "courier [bitstream]:10" , XFLD names won't be supported anymore.
That means if you want to save your font setting for kvim in your ~/.gvimrc, you should use something like : if has("gui_kde") set guifont=courier [bitstream]:10
so that it does not give an error when you start gvim (gtk vim) ;)

but this is not yet ready so stay tuned :)


by Philippe Fremy (not verified)

I highly suspect it is messing with the background hint.

Vim has two background modes: dark and light, and sets its colorscheme accordingly.

by anonymous (not verified)

...is the argument in the FAQ that there was not enough space in KDE's CVS repository. Where's that from? There's gigabytes of free space on the CVS server...

by ac (not verified)

I used to see while using anoncvs

cvs could not create /home/kde/tmp/fkjbgosdvjb: no space

Or something like that. Maybe that's what they are talking about?

by Mickael Marchand (not verified)

I discussed with someone on IRC which explained me that the CVS server was quite full at the time we wanted to add the Vim runtime package in CVS (note that full KVim CVS is more than 16 Mb). cvs.kde.org may have a lot of space, probably some mirrors don't have so much.

checkouting kdenonbeta already take hours ;), adding the 16 Mb of KVim would not have helped it. Morover, KVim cannot be anymore considered as a alpha or beta program, that seemed logical to us to have our own repositery.

But don't worry Tuxfamily is a good hosting place :)
CVS is fast and has a lot of space, this is all KVim needs :)

by Claus Rasmussen (not verified)

I have looked at the KVIM homepage but I fail to find any mention of where to download the source. ftp.tuxfamily.org seems only to contain some Exim files and a mirror of the linux kernel sources.

Did I miss something ?

by Mickael Marchand (not verified)

you probably missed the links on our download page ;)
check our download page carefully, section "What do you need ?", there are links but these are not displayed correctly (no underline): the filenames are the links, click on them.
We will correct this ;)

Sorry for the inconvenience,

by Claus Rasmussen (not verified)

> the filenames are the links, click on them.

Yep, thats it ! I have waited for KVIM soo long, so I was quite frustrated being unable do download the thing :-)

Thanks for your good work.


by wiki (not verified)

... of having vim in my html textareas. I could edit wiki (http://twiki.org)
with vim. Will that be possible having a kvim part?

by Mickael Marchand (not verified)

it looks like you(someone ? a khtml coder ?) will have to hack this into khtml ;)
but this is not yet supported


by Evan "JabberWok... (not verified)

As an even better solution, right click on a textarea to get an option of "edit With...". Then you can use a nice editor to spellcheck and so on.


by Jérôme Loisel (not verified)

Well... It's good that this works at all, but I wouldn't go so far as to call it "even better". Having the choice of using a real editor instead the basic text widget is good. "Even better" would be what he suggests: not being confronted with a basic, feature-less text widget, but having a real editor from the get-go, anywhere and everywhere.

Would make working with Zope much nicer too.

by troller (not verified)

EMACS rulez!

by Bob (not verified)

Ah but ViM rulez!!!!!!!!!!!!!!

by J.A. (not verified)

Yes it is great news :))
After using vim for a long time, I end up moving to Xemacs though.
I still use vim sometimes, mostly when I'm working in console, but vim
is just not enough for my needs.
So, yes I love the idea, many people will use it a lot, I'll probably use
it sometimes, but I want a KXemacs too!!! :-)


by jargon (not verified)

Hi There.

First of all, great work! I had been waiting for this to happen for a long time and always knew that it would be just a matter of time. We have also startded up porting Emacs to QT/Kde but it is an enormous task.

About the icons in your screendumps, how do you get Kvim to pick up the KDE icons instead of the one's from GVim? Has anyone gotten Kvim with KDE icons instead of GVim? This totally throws of the uniformity of this wonderful application.



by orzel (not verified)

It would really makes sense to have a K[x,]emacs. I think it's probably even more difficult than porting vim. I won't do it, though, I really don't know emacs..
With respect to the icon, we know lot of people want the kde icon. We were actually using them, but as some vim icon are missing from kde
standard icon, we had to switch back to vim/gvim icons. We'll try to get the missing ones.

by Kev Kde User (not verified)

Hey, does anyone know why I keep getting the following errors when I load vim? Something changed a bit ago and I don't know what, but other users don't get this.

viminfo: Illegal starting char in line: ^?ELF^A^A^A
viminfo: Illegal starting char in line:
viminfo: Illegal starting char in line: Õ^F
Hit ENTER or type command to continue

by orzel (not verified)

Hey, better report this kind of error on our mailing list :
[email protected]. Seems like you are editing some exe. How do you load kvim ? Is the part or the whole application ?

by Kev Kde User (not verified)

No - this isn't specific to kvim - it's been happening to me for a bit on
any vim session. There must be some binary in one of my config fils, but I'm not enough of a vim expert to know yet. Was just wondering if this struck anyone.

by samuel (not verified)

you seem to have an elf file setup so it is read as a config file.

It will be in ~/.vimrc ... first cat this and check that it is a text file and then follow the links from there ... somewhere you will be reading in a binary file

by Philippe Fremy (not verified)

Looks like your .viminfo file is an elf executable. You can simply delete it, viminfo only stores some kind of session information.

by srinivasu maddula (not verified)

when i open any file using vi editor, when i quit at the command line, it is giving "cant write viminfo file [NULL!]"
I ve deleted .viminfo file also. it repeats.

suggest me the best solution to this prob.

by ICE (not verified)

the above given solution works for me.

i.e. remove all .viminfo files present in your home directory.

I use following command in my home directory:

rm -r .viminf*