PyBindGen Type Narrowing

Today I finished another important feature in my python bindings generator:
automatic type narrowing of C++ class pointers. It was implemented with a std::map<const char*, PyTypeObject*>, mapping type names to Python wrappers, and the typeid C++ operator, which uses RTTI to return type information in runtime, including type name.

This comes on the heels of supporting function/method/constructor overloading, finished a few days ago. I'm getting increasingly optimistic about pybindgen. It does few things, but does them well. It will hopefully make the (python) world a better place to live in :P

Ubuntu Dell PCs in Europe

Nice to see Dell Ubuntu PCs being sold in Europe. However, one has to wonder why the laptops being sold in Europe are at most Intel Dual Core and Intel 950 graphics, noticeable inferior to those being sold in the U.S., namely Intel Core2 Duo and Intel 965 graphics. What's wrong? Do Europeans require less powerful hardware? Are we being discriminated? *sigh*

GEdit with Emacs Colors

Following up on Paolo Borelli's post about a Dark Tango gedit color scheme, I decide to write a color scheme based on the default GNU Emacs colors circa RedHat 5.2. It basically has a dark slate grey background, and wheat foreground. All these years, since RedHat 5.2, my first Linux distribution, I got used to GNU Emacs as my editor of choice for serious tasks (programming, LaTeX).

I have customized a few things from the default Emacs color scheme, most notably getting rid of the awful red foreground for comments (ugh!) in favour of a less intrusive grey.
The other notable change that I made was the addition of syntax highlighting for symbols, including operators, parenthesis, brackets, curly braces, etc., because I believe it really helps read the code better. Emacs in fact does not natively support highlighting of symbols, but since it is highly extensible I was able to add support for it.

Anyway, my emacs color scheme for gedit can be found here. Playing a bit with gedit with this color scheme, once again I tried to get the feeling on whether I could ever switch from emacs to gedit, and the answer is sadly still no. Here's some of the reasons:

1. Gedit still does not have the notion of indentation offset, and only has tab width. In emacs, you can have tab width set to 8, but if you set indentation offset to 4 then pressing tab indents with 4 spaces, not one tab. In gedit you have to change the tab width to 4, which has disastrous side effects on source files that are using real tab characters for indentation. This is a really serious problem IMHO.
   
2. Gedit is generally not very smart about indentation. Emacs usually knows how to indent a line based on syntax analysis of the surrounding context. I guess I can leave without it, but it would be really nice to have. But, yes, I realize this is very hard to implement for only a little gain.
   
3. Gtk's default cursor is very thin and easy to lose track of it. In contrast, Emacs' cursor is big and blocky, but at least you never lose track of it. Fortunately I was able to kind of work around with a gtkrc style file, although it's not perfect.
4. I already mentioned the symbols/operators problem. Gedit does not natively support operators in most language files; at least not C/C++/Python, which is the ones I care about. I'm not sure if I can fix this easily. I can define color schemes, but I wonder if I can customize language definitions, add new information to them in a inheritance style?
5. The modelines plugin needs more work; it keeps ignoring many of the modelines on my files.
   

In conclusion, there are some problems in gedit and I will not switch to it yet. However, it does support Python plugins, and therefore most of the problems should be fixable given a bit of time and patience. Lucky for me I'm on vacations, so I might yet revisit this issue before the end of the month.