colin@
colino.net

I’m leaving to Fosdem! Time to practice that awful english accent I have…
It also means I’ll be unreachable until tomorrow. (I’ll have my laptop at Fosdem, so will be able to read my mails).

I uploaded a snapshot of Sylpheed-Claws 1.0.1cvs15.5 here. I’ll probably soon stop doing it, as the next release should be gtk2.

After Christoph’s commit from Tuesday, labelled “change Privacy-API to C++”, I almost wanted to fork Claws, because the more time passed, the more I felt Sylpheed-Claws wasn’t progressing in the best (in my opinion at least) direction. After having discussed that with Paul, I brought up the subject on IRC. A very little flamewar ensued, which was stopped suddenly by Christoph who decided to take a break wrt Claws. As it may sound egoistical, I am rather happy with this, because forking would have been more painful, and it had become apparent than most of the other developers (and users) were agreeing with my views on Claws future. The next page contains excerpts of a long mail I wrote to Paul to explain him my motivations towards forking.

I just uploaded a gtk2 snapshot of sylpheed-claws 1.0.1cvs7.1.
Changes since cvs1.3 include a contextual menu item on email addresses, sync with main, accentued chars fixes (wrapping, email address parsing), two crasher fixes, and a mail-mangling fix.

I have the strange impression that I spent way too much time on fixing charset-related problems on Sylpheed-Claws.
First the badly encoded mail headers with raw 8 bit in them, where all I can do to fix undisplayable (as utf-8, the gtk2 internal charset) strings is

• guess the original encoding (actually, see if it can be converted from the user’s locale charset to utf8),
• or parse the whole string for undisplayable chars and replace them with an underscore (yay for speed)

Then, the conversions needed for local files and directory. This one is ugly, and the best thing to do is: Never use extended chars in your folder’s names. :-/

After that there are the xml files, which were happily reporting to be encoded in UTF-8, whereas they were encoded in the user’s locale charset, and then, read as UTF-8 (with a fallback to the user’s charset to fix the obvious errors this made happen). Fixing the xml files so they are written like they should be, obviously, broke people’s addressbooks and so on.

And of course the irrelevancy of old libc functions, like ispunct() that happily returns true whenever it reaches an UTF-8 encoded extended char. This particular bug made me realise that ispunct does not do what it claims to do:

ispunct()
    checks for any printable character which is not a space or an alphanumeric character.

And there I thought ispunct() would test if the character was actually a punctuation char.

But why, why, didn’t our “ancestors” think about such things and began with creating intelligent norms showing at least a bit of forward-thinking?

(And one day I’ll rant about the whole \r, \n, \r\n mess, too).