Slashdot Mirror
The Union of Vim with KDE
Philippe Fremy writes "Thomas Capricelli, Mickael Marchand and me are pleased to present the first ever stable version of KVim, finally bringing "the power of VIM with KDE's friendliness".
This release contains a port of the standalone editor Vim 6.0 to Qt/KDE (2 and 3) and a KDE KPart Component. The component can currently embed either of GVim or KVim in Konqueror (screenshots), with out-of-process embedding. Further work is required before proper support for KDevelop, KMail and Kate is available, but things are moving forward."
As everyone knows, Vim is the best (only?) text editor, and KDE is the best (only?)
desktop system. Heh.
Defies the whole persona of vim. vim loses what makes it useful when you stick it in a window and add menus and buttons.
vim is all about those wierd keystrokes you learn that funnily enough grow on you and multiply your productivity.
While I'm sure you can still do this with kvim, I don't see what would get a real vim user to use kvim rather than just vim in konsole.
Nice idea, like I said, but I don't expect too much takeup.
Blearf. Blearf, I say.
If this is a "blatant attempt" to start a flamewar, then you my friend, are guilty of putting the first match to the kindling.
;)
You could have just ignored it
PGP KeyId: 0x08D63965
Since it's not in italic, chances are that this was CT's comment, and not the original article writers.
And while they wouldn't dance around a camp fire, the hate isn't exactly pretended either. KDE/Gnome has become one of the holy wars of computing: vi/emacs (go nano!!!), littleendian/bigendian, OOP, and many other venerable silly battles. It's actually an ideological battle - GNOME was started in the first place because KDE was based on Qt, which isn't GPL. Thus, the rush to create a GPL'd window/widget toolkit (GTK) and environment.
Well, it's been a high time to get real components on UNIX. Considering that UNIX (and Linux) are all about small tools doing their jobs and integrating with each other, components are logical extension of pipes... Now I just wish I had the time to start a project - I'd probably write component browser/method invoker module for zsh. :)
Anyway... kudos to VIM folks for getting this right.
--
I refuse to use
When I fell back into the Unix/Linux world some four years ago, my biggest crisis was finding a text editor. The obvious choice for me was Vi in a term window (I've been using Vi since Jimmy was president). Alas using it in a windowing environment presented special problems. The big one is that I kept forgetting which mode I was in. Maybe you can have a half-dozen windows open and keep a state diagram of every one in your head. I can't. I needed an editor that was stateless, or at least less stateful than vi(m)-in-a-window.
Lucky for me, this was right when the Vim people perfected GVim, a version that integrated itself with various windowed environment. A paste is a paste, never mind what mode you're in. That by itself was enough for me to send a check to Bram's orphans. (I assume everybody else has?) The rest -- macros, synax colors, incremental search, being able to use the same editor on different platforms -- was just gravy.
So we've actual had this personna-defying version of Vim for quite some time. The Linux port uses GNOME widgets, but runs under KDE, no problem.
Also, you shouldn't assume that Vim is strictly for keep-my-hands-on-the-keyboard geeks. I know people who are put off by the weird modal keystrokes that Vim inherited from Vi. But they use Vim anyway, because it's the best comprimise available between power and functionality. Most editors are either to limited (KEdit) or infected with Feature Elephantitis (EMACS). Vim strikes a nice balance.
I find it absolutely fascinating that people think that the UNIX world lacks features found in Windows because, well, because of what? Do you seriously believe that people didn't have the resources to create this for UNIX?
The fact is that OLE (and its successors) are unreliable kludges. They grew out of some hacks trying to make Office components talk to one another, for which they were sort-of OK. But when applied to arbitrary applications, the GUI merging and process model they give you result in lousy user interfaces and unreliable applications. UNIX didn't get them because UNIX users didn't see a pressing need for them; other mechanisms work better.
Even if you think that what OLE was trying to do is actually useful, OLE and its successors are about the worst way of implementing it: unportable, low-level hacks that are difficult to version and don't protect programs from one another. OLE is really mainly an attempt to give C++ programs at least a little bit of what systems like Smalltalk and Java give you for free. And, surprise, Microsoft finally caught on and replaced the whole OLE/COM/ActiveX mess with C#/CLR (of course, there is some backwards compatibility and they use the OLE/COM terminology to explain the new functionality in C#/CLR).
From the KVim page:
KVim is released under the smae 'charityware' licence as vim. Please see the vim website for more info.
Why do I smell licensing problems here? That is, unless the developers have a commercial Qt license, they are required to distribute any software linked with Qt under the GNU GPL.
I believe that would be the second time, as Vim was previously linked with libgpm (I don't know if it currently is), which is also distributed under the GNU GPL.
That is 100% correct. Let's face it: KDE and Gnome are playing catch-up. They both will be obsolete when somebody invents a truly immersive system. A system that is more like Java or C#, but much better. More like the best combination of Self, Smalltalk, Ruby and Haskell. Now that would be cool. And with an inventive GUI that is easy to integrate with the CLI to top it. Additionally, it's got to be faster than smalltalk. Squeak may be nice for simple and small projects, but it's a dog under stress. Therefore you need native compilation and optimizations. You need to be able to compile to static native code. Reflectivity and mutability comes at a price too high for core parts of the system, but should be present at an even higher price - recompilation. Everything should be optional though. You should even be able to run any parts under an interpreter if you fancy that, like in Ruby.
Of course, to pull this off you need years and years of research-time. Which is why it's not so easy and will probably not be available in the next 15 years. Unless someone are already on their way.. The real trick is integrating/translating already developed works separately. I don't think this is feasible in a meaningful way the next 100 years, but the Tunes-people seem to believe so. However, dreamers don't produce any code.
Me? I have a long lifeline, but not as long as all my ideas. Besides, you need to understand CS in such gory details it starts messing up your worldviews. I'll devote my time on people instead.
You are full of shit if you are even thinking of claiming of writing code at 90wpm.
Furthermore, most well coded gui applications have accelerator keys for all menu options which means that you never have to leave the keyboard.
Oh and BTW, if you haven't noticed, the quality of Linux applicatiosn has improved dramatically as the linux development tools have improved.
It is really a shame that people like yourself are too ignorant too learn new ways to increase your productivity.
Or is it that you think that doing things the hard way makes you look smarter. Hate to break the news, it doesn't and most of your peers will think poorly of you.