Bad bad vim

New post after so long of inactivity. And negatively oriented, toward bashing my favorite editor: vim.

I'm not sure why people are calling emacs a kitchen sink of editors when vim is on a good path to became, even a bigger one.

From time to time I fire up emacs (recently a little bit more often than before after I discovered Evil, vim uber emulation mode for emacs, making emacs usable to us, poor vi/vim users) to see what progress is made in editor world and how vim is keeping up with it.

Sometimes I am happy why I'm still using vim (speed, integrated spell check) and sometimes I'm jealous for some features vim probably will never have (external processes inside editor, dbus support, extension language) or are implemented badly (syntax coloring, extension language, own spell check instead already existing, like aspell, ispell or else).


Well, see, for emacs we have Babel and I'm very happy with it. Install emacs and install Babel and things works.

Vim has also nice one, called VimTranslator, except it supports only Google Translate. This is not an issue, except you have to have installed ruby to use it.

No matter I'm not using ruby at all, to use full vim version I must install ruby. Probably because to write vim extensions you can use 10 different languages, forcing your users to install them and everything those languages requires. Yuck!

Emacs is not perfect either, but to extend it I need to learn single language (elisp) and I can be productive. For vim, I can choose between half baked junk called vimscript or something better in form of heavyweight alternatives like python, perl, ruby... What to expect in the future; java maybe?

No more eFLTK

In the last month there has been a lot of changes in repository. First of all, maybe the most interesting change is that edewm (window manager) was replaced with pekwm, making EDE now fully eFLTK free! This is the major step we headed to in last few years when decided to abandon eFLTK and fully focus on stable (and more maintable) FLTK 1.x.

I chose pekwm simply because it depends only on C++ compiler and X11 libs. I used it (and still using it) heavily with other EDE parts and it works without any major problems. Also, quite important thing for window manager was to have good window manager specification support, so users can replace them without any hassle.

Thanks to ChristTrekker suggestion I played with FLTK based awflwm, but it is still quite behind EDE needs.

Also, important news is how panel (ede-panel) got system tray support (implementing almost full system tray specification, excluding messaging part). This removed one huge limitation for current EDE usage, as more and more applications (and daemons) store own status in tray. Here is image with some apps running on Fedora 15:

There could be some issues I missed, but this thing is working and I'm using it daily (with skype and pidgin of course :)).

ede-launch got some important addition in form of support for preferred applications. This introduced new tool, called ede-preferred-applications from where user can select preferred web browser or terminal. I'm sure you already seen it in form of exo-preferred-applications from Xfce or similar tool from GNOME.

Basically, with this you will be able to run preselected terminal or browser, or simply leave ede-launch to guess your input and deduce what to run.

ede-launch can now directly run .desktop files too, which will simplify some code in ede-desktop component.

So to summarize, you can do this:

ede-launch http://www.google.com  # run selected browser
ede-launch foo@foo.com # run selected mail client
ede-launch --launch terminal ls -la /  # list directory in preferred terminal

As ede-launch is used to start almost everything, these features will become quite handy.

What are the major things left to be done before release? There is a small issue with long long support on FreeBSD's Xorg distro (EDE is compiled with -pedantic support yielding error reports when long long is detected, as it is not supported by C++ standard) and iconv inside pekwm (also on FreeBSD) that needs to be resolved. Also, I would like to review translation support and add intltool for easier string extraction from files that are not source code (conf and .desktop files, theme sources and such).

Memory applet and more

Few days ago I pushed a new applet that will show memory and swap usage.

The shot is above; noting smart behind it, but can be usable especially if you use firefox often or have Fedora/Ubuntu with tons of background processes ;)

edelib got facelifing in debug facility, inspired with debug functions and macros from glib. Previously, debug functions would simply write filename/line/text combination, without knowing from which application is emitted, like:

src/Window.cpp:53: loading 'edeneu' theme

Things become pretty messy when you get a bunch of reports from various place: edelib, ede-desktop, configuraion program(s) and etc. By introducting E_DEBUG_DOMAIN, which is set in compile phase, things looks like this:

[edelib] src/Window.cpp:53: loading 'edeneu' theme
[ede-conf] ede-conf/ede-conf.cpp:105: Can't load config

(of course the last line is pretty descriptive, but things got from edelib aren't obvious)

Also, things related to web hosting are still on hold. I contacted Csoft (as suggested by anonymous in previous post comments), but I'm still waiting for reply. Not sure how can I rely on these guys if I need to wait almost a month for a simple answer...