So 26 listopadu 2005
(Answer to discussion caused by my message “Kate-part syntax file for highlighting VO files” on firstname.lastname@example.org (Message-ID email@example.com) about creating Kate syntax highlighting file for VimOutliner).
Probably it is just brain damage of mine caused by many years of using Windows, but somehow even after couple of years of using vim it still feels very strange and unfamiliar. However, discussion cannot be made around feelings, so here are some rational (or semi-rational) reasons, why I begun to think a lot about leaving vim.
I guess that you are a programmer (or some other CS-guy—why would you edit Common Lisp scripts?) and so the most of your time is spent editing plain text in a text editor. That is not my case, and I found myself to spend bigger and bigger proportion of time in some kind of KDE applications—KMail, KNode, LyX (OK, it is not KDE-based yet, but with similar user interface), Konqueror, which is probably the reason that even when I was editing plain text files (Python source code, R-scripts, different XML files) it felt better when I did it with kate (BTW, talking about XML files, kate’s XML plugin is probably the only comparable environment for editing XML files to Emacs’s PSGML I’ve met so far). It seems to me that more and more I work with KDE it is more and more difficult to achieve satori (I guess you have already read “Zenclavier: Extreme Keyboarding” by Tom Christiansen, it should be obligatory reading for any vi-geek) and contrary to the Tom’s article it was more and more simple to achieve it working with KDE programs. As if the most important condition of the satori is not the best design of the computer program (and there could be much said about clever design of vi—Tom has already wrote it), but uniformity of the user experience. It doesn’t mean, that there are many ways how to screw up design of a text editor (for example, no one explained me well, what are toolbars good for editing texts), but that the design is not everything. When you achieve relatively good design (and of course all main text editors for Linux and many other for Windows or Mac did it) then the familiarity can kick in and you can achieve oneness with your computer.
This leads to some rather strange conclusions. If the homogeneity of environment is the most important requirement, then the best Desktop environment is the one which provides the most homogenous user experience (which is IMHO one of the reasons why OS/2 failed and why Linux achieved competitivness with Windows for general public IMHO only in the last couple of years, although both desktop environments were much better in terms of their window managers, background philosophy etc. for many many years already). True, I have never tried GNOME hard enough in the last years to make any reasonable comparisons (so this should not be understood as a shot against GNOME in the KDE-GNOME holy war), but it seems to me that KDE is currently the best desktop environment on Linux (and not only on Linux???) in terms of its overall homogeneity. For each application which makes KDE you can probably find a comparable or better alternative (although sometimes you have to search really hard—for example, KMail and Konqueror are just bloody good programs in themselves), but each of these alternatives leads to the special world of their own not that much consistent with anybody else (I have to note though that I almost never use KOffice, which could change balance towards OpenOffice.org and GNOME for others). Mozilla programs are one world for itself, Emacs and GVim are kind of addictive drugs closing ones’ mind to anything else, and closeness is probably present pretty much in OpenOffice.org as well.
And then there are some just plain technical reasons why I am getting worried about any dependency on GVim—see for example this thread or the thread I have originated in comp.editors. No, and I don’t think that yzis is the answer (message “Why lua? or questions about yzis”, msg-id 1286335.sMIPMRb7Dl@blahoslav.ceplovi.cz on firstname.lastname@example.org).