emacs — jd:/dev/blog

The bad practice in FOSS projects management

Thu, 09 Jun 2016 00:00:00 GMT

During the OpenStack summit a few weeks ago, I had the chance to talk to some people about my experience on running open source projects. It turns out that after hanging out in communities and contributing to many projects for years, I may be able to provide some hindsight and an external eye to many of those who are new to it.

There are plenty of resource explaining how to run an open source projects out there. Today, I would like to take a different angle and emphasize what you should not socially do in your projects. This list comes from various open source projects I encountered these past years. I'm going to go through some of the bad practice I've spotted, in a random order, illustrated by some concrete example.

Seeing contributors as an annoyance

When software developers and maintainers are busy, there's one thing they don't need: more work. To many people, the instinctive reactions to external contribution is: damn, more work. And actually, it is.

Therefore, some maintainers tend to avoid that surplus of work: they state they don't want contributions, or make contributors feel un-welcomed. This can take a lot of different forms, from ignoring them to being unpleasant. It indeed avoids the immediate need to deal with the work that has been added on the maintainer shoulders.

This is one of the biggest mistake and misconception of open source. If people are sending you more work, you should do whatever it takes to feel them welcome so they continue working with you. They might pretty soon become the guys doing the work you are doing instead of you. Think: retirement!

Let's take a look at my friend Gordon, who I saw starting as a Ceilometer contributor in 2013. He was doing great code reviews, but he was actually giving me more work by catching bugs in my patches and sending patches I had to review. Instead of being a bully so he would stop making me rework my code and reviews his patches, I requested that we trust him even more by adding him as a core reviewer. time contribution.

And if they don't do this one-time contribution, they won't make it two. They won't make any. Those projects may have just lost their new maintainers.

Letting people only do the grunt work

When new contributors arrive and want to contribute to a particular project, they may have very different motivation. Some of them are users, but some of them are just people looking to see how it is to contribute. Getting the thrill of contribution, as an exercise, or as a willingness to learn and start contributing back to the ecosystem they use.

The usual response from maintainers is to push people into doing grunt work. That means doing jobs that have no interest, little value, and probably no direct impact on the project.

Some people actually have no problem with it, some have. Some will feel offended to do low impact work, and some will love it as soon as you give them some sort of acknowledgment. Be aware of it, and be sure to high-five people doing it. That's the only way to keep them around.

Not valorizing small contributions

When the first patch that comes in from a new contributor is a typo fix, what developers think? That they don't care, that you're wasting their precious time with your small contribution. And nobody cares about bad English in the documentation, don't they?

This is wrong. See my first contributions to home-assistant and Postmodern: I fixed typos in the documentation.

I contributed to Org-mode for a few years. My first patch to orgmode was about fixing a docstring. Then, I sent 56 patches, fixing bugs and adding fancy features and also wrote a few external modules. To this day, I'm still #16 in the top-committer list of Org-mode who contains 390 contributors. So not that would call a small contributor. I am sure the community is glad they did not despise my documentation fix.

Setting the bar too high for new comers

When new contributors arrive, their knowledge about the project, its context, and the technologies can vary largely. One of the mistakes people often make is to ask contributors too complicated things that they cannot realize. That scares them away (many people are going to be shy or introvert) and they may just disappear, feeling too stupid to help.

Before making any comment, you should not have any assumption about their knowledge. That should avoid such situation. You also should be very delicate when assessing their skills, as some people might feel vexed if you underestimate them too much.

Once that level has been properly evaluated (a few exchanges should be enough), you need to mentor to the right degree your contributor so it can blossom. It takes time and experience to master this, and you may likely lose some of them in the process, but it's a path every maintainer has to take.

Mentoring is a very important aspect of welcoming new contributors to your project, whatever it is. Pretty sure that applies nicely outside free software too.

Requiring people to make sacrifices with their lives

This is an aspect that varies a lot depending on the project and context, but it's really important. As a free software project, where most people will contribute on their own good will and sometimes spare time, you must not require them to make big sacrifices. This won't work.

One of the worst implementation of that is requiring people to fly 5 000 kilometers to meet in some place to discuss the project. This puts contributors in an unfair position, based on their ability to leave their family for a week, take a plane/boat/car/train, rent an hotel, etc. This is not good, and everything should be avoided to require people to do that in order to participate and feel included in the project and blend in your community. Don't get me wrong: that does not me social activities should be prohibited, on the contrary. Just avoid excluding people when you discuss any project.

The same apply to any other form of discussion that makes it complicated for everyone to participate: IRC meetings (it's hard for some people to book an hour, especially depending on the timezone they live in), video-conference (especially using non-free software), etc.

Everything that requires people to basically interact with the project in a synchronous manner for a period of time will put constraints on them that can make them uncomfortable.

The best medium is still e-mail and asynchronous derivative (bug trackers, etc), as it is asynchronous and allow people to work at their own pace at their own time.

Not having an (implicit) CoC

Codes of conduct seem to be a trendy topic (and a touchy subject), as more and more communities are opening to a wilder audience than they used to be – which is great.

Actually, all communities have a code of conduct, being written with black ink or being carried in everyone's mind unconsciously. Its form is a matter of community size and culture.

Now, depending on the size of your community and how you feel comfortable applying it, you may want to have it composed in a document, e.g. like Debian did.

Having a code of conduct does not transform your whole project community magically into a bunch of carebears following its guidance. But it provides an interesting point you can refer to as soon as you need. It can help throwing it at some people, to indicate that their behavior is not welcome in the project, and somehow, ease their potential exclusion – even if nobody wants to go that far generally, and that's it's rarely that useful.

I don't think it's mandatory to have such a paper on smaller projects. But you have to keep in mind that the implicit code of conduct will be derived from your own behavior. The way your leader(s) will communicate with others will set the entire social mood of the project. Do not underestimate that.

When we started the Ceilometer project, we implicitly followed the OpenStack Code of Conduct before it even existed, and probably set the bar a little higher. Being nice, welcoming and open-minded, we achieved a descent score of diversity, having up to 25% of our core team being women – way above the current ratio in OpenStack and most open source projects!

Making people not English native feeling like outsider

It's quite important to be aware of that the vast majority of free software project out there are using English as the common language of communication. It makes a lot of sense: it's a commonly spoken language, and it seems to do the job correctly.

But a large part of the hackers out there are not native English speakers. Many are not able to speak English fluently. That means the rate at which they can communicate and run a conversation might be very low, which can make some people frustrated, especially native English speaker.

The principal demonstration of this phenomena can be seen in social events (e.g. conferences) where people are debating. It can be very hard for people to explain their thoughts in English and to communicate properly at a decent rate, making the conversation and the transmission of ideas slow. The worst thing that one can see in this context is an English native speaker cutting people off and ignoring them, just because they are talking too slowly. I do understand that it can be frustrating, but the problem here is not the non-native English speaking, it's the medium being used that does not make your fellow on the same level of everyone by moving the conversation orally.

To a lesser extent, the same applies to IRC meetings, which are by relatively synchronous. Completely asynchronous media do not have this flaw, that's why they should also be preferred in my opinion.

No vision, no delegation

Two of the most commonly encountered mistakes in open source projects: seeing the maintainer struggling with the growth of its project while having people trying to help.

Indeed, when the flow of contributor starts coming in, adding new features, asking for feedback and directions, some maintainers choke and don't know how to respond. That ends up frustrating contributors, which therefore may simply vanish.

It's important to have a vision for your project and communicate it. Make it clear for contributors what you want or don't want in your project. Transferring that in a clear (and non-aggressive, please) manner, is a good way of lowering the friction between contributors. They'll pretty soon know if they want to join your ship or not, and what to expect. So be a good captain.

If they chose to work with you and contribute, you should start trusting them as soon as you can and delegate some of your responsibilities. This can be anything that you used to do: review patches targeting some subsystem, fixing bugs, writing docs. Let people own an entire part of the project so they feel responsible and care about it as much as you do. Doing the opposite, which is being a control-freak, is the best shot at staying alone with your open source software.

And no project is going to grow and be successful that way.

In 2009, when Uli Schlachter sent his first patch to awesome, this was more work for me. I had to review this patch, and I was already pretty busy designing the new versions of awesome and doing my day job! Uli's work was not perfect, and I had to fix it myself. More work. And what did I do? A few minutes later, I replied to him with a clear plan of what he should do and what I thought about his work.

In response, Uli sent patches and improved the project. Do you know what Uli does today? He manages the awesome window manager project since 2010 instead of me. I managed to transmit my vision, delegate, and then retired!

Non-recognition of contributions

People contribute in different ways, and it's not always code. There's a lot of things around a free software projects: documentation, bug triage, user support, user experience design, communication, translation…

It took a while for example to Debian to recognize that their translators could have the status of Debian Developer. OpenStack is working in the same direction by trying to recognize non-technical contributions.

As soon as your project starts attributing badges to some people and creating classes of different members in the community, you should be very careful that you don't forget anyone. That's the easiest road to losing contributors along the road.

Don't forget to be thankful

This whole list has been inspired by many years of open source hacking and free software contributions. Everyone's experience and feeling might be different, or malpractice may have been seen under different forms. Let me know and if there's any other point that you encountered and blocked you to contribute to open source projects!

Gnus notifications

Wed, 29 Aug 2012 00:00:00 GMT

Today, I've merged my Gnus notifications module inside Gnus git repository. This way, it will be available for everybody in Emacs 24.2.

This module allows you to be notified via notifications-notify (the Emacs implementation of the Freedesktop desktop notifications) on new messages received in Gnus. It can also retrieves contacts photo via gravatar.el and google-contacts.el to include them in the notification.

To enable it in Emacs > 24.1, you just have to add the following line to your Gnus configuration file:

(add-hook 'gnus-after-getting-new-news-hook 'gnus-notifications)

If you want to download it and use it stand-alone for a previous Emacs version, you can fetch the latest file revision and load it before adding the previously given line.

Emacs configuration published

Tue, 24 Jul 2012 00:00:00 GMT

I've finally published my Emacs configuration.

This took me a while, since I had personal information inside (like passwords). Recently, I've been able to move them away and can now publish everything in my Git repository.

It's probably not yet usable from scratch, since I didn't include the bootstrap code for el-get. But you can at least lurk and grab some ideas or lines of code. And do not hesitate to ask me anything about it!

Note that I'm using Emacs development version (trunk), so it's possible that some things do not work with (old) released Emacs versions.

ERC notifications

Sat, 21 Jul 2012 00:00:00 GMT

Today, I've merged my erc notifications module inside Emacs trunk. This way, it will be available for everybody in Emacs 24.2.

This module allows you to be notified via notifications-notify (the Emacs implementation of the Freedesktop desktop notifications) on private message received on IRC, or when your nickname is mentioned on a channel.

To enable it in Emacs > 24.1, you just have to add the following line to your configuration file:

(add-to-list 'erc-modules 'notifications)

If you want to download it and use it stand-alone for a previous Emacs version, you can fetch the latest file revision and load it before adding the previously given line.

Ten years as a Debian developer

Fri, 24 Feb 2012 00:00:00 GMT

Ten years ago, I joined the Debian project as a developer.

At that time, I was 18 and in my first year at university, hanging out with the TuxFamily system administrators, which included 3 french Debian developers (sjg, igenibel and creis).

I was learning Debian packaging while working on VHFFS, and decided to package one or two non-yet-packaged software for Debian. My friends pushed me into the NM process, and less than 2 months later I was a Debian developer. One have to admit that back in the days, the NM process was really fast if you were able to reply to the questions quickly. :-) I think I became the youngest developer among Debian's ones.

That was my first steps in a Free Software project, and it was really exciting.

In 10 years, I've been doing a lot of different things for Debian. Sure, I've been using it all the years long, but let's recap a bit what I did, from what I recall.

My first Debian only project was apt-build around 2003, and later rebuildd in 2007.

I built the Xen packaging team in 2005, I've been a Stable Release Manager for a year in 2006, and did heavy bug squashing to release Etch that same year.

I also was an Application Manager in 2006 and managed the application of 2
Debian developers (Jose Parrella and Damián Viano).

I admit I've been less active in Debian after 2007, mainly because I was busy working on awesome, GNU Emacs and others software.

Since 2011, I joined the OpenStack packaging team and I'm working on OpenStack on a (almost) daily basis.

I don't know how many packages I touched, managed or updated, but that should be one or two hundreds. I still maintain 53 of them.

After all, the adventure has been really pleasant, and I had the chance to work with and meet fabulous and smart people. I always liked this project and what it's trying to do.

After all these years, I'm definitively staying! See you in another 10 years, folks! :)

Google Contacts for Emacs

Mon, 26 Sep 2011 00:00:00 GMT

I finally finished a thing I was really missing: accessing my Google Contacts from Emacs.

That's now possible, thanks to my new google-contacts.el package.

It includes searching for any contact and displaying the result in a window.
You can also jump to a contact from Gnus by pressing a
key, and complete e-mail addresses while composing a mail.

OAuth 2.0 for Emacs

Fri, 23 Sep 2011 00:00:00 GMT

This week, I've finished my OAuth 2.0 client implementation for GNU Emacs.

I have imported it into GNU ELPA so Emacs 24 users will be soon able to install it using the new Emacs packaging system.

OAuth 2.0 can be used to access, among others, Google APIs or the Facebook Graph API.

Org contacts now part of org-contrib

Fri, 18 Mar 2011 00:00:00 GMT

Thanks to my recent promotion allowing me to commit directly in Org-mode, I've moved Org-contacts into the contrib directory of the Orgmode distribution.

My latest contributions to the Emacs' world

Tue, 01 Mar 2011 00:00:00 GMT

I spend too much time writing Emacs Lisp code these days. Unfortunately, the more I do the more I find new useful tools to improve my work-flow and save time for doing more Lisp. D'oh.

I did not work on any big thing these last weeks, so I'm thinking it's a good time to talk about the various code and patches I sent to multiple Emacs packages.

el-get

el-get, a fabulous tool that installs and handles all the external Emacs packages I use. A friendly war started on the development list about autoloads handling. The discussion was overall pointless, since we had a very hard time to communicate our ideas, and we did not understand each others several times.

In the end, el-get now supports autoload correctly and do not load automatically all your packages, improving the startup time, and using the Emacs way to do things. Which is always better, obviously.

git-commit-mode

I've started to use git-commit-mode some times ago. I usually use git-commit with the -v option to see what I'm committing. I though it would be useful to color the diff with diff-mode, so I wrote a patch just to do that, which
was merged today by Florian.

magit

Some weeks ago, I decided to give a try to magit, and loved it. I am not always using it, but for basic operations it is very useful. But I really soon found some things I did not like and therefore send patches to enhance it.

First, I've added a patch to honor status.showUntrackedFiles which I use in my home directory. In the mean time, I've also added a patch to allow adding an arbitrary file.

Yesterday, I sent another pull request, not closed for now, which adds the possibility to visit files in another window from a diff file, and the support for add-change-log-entry directly from the displayed diff. Useful for these old projects still using ChangeLog files but accessible through git (hi Emacs & Gnus!).

Gnus

Nothing remarkable, but I write a couple of fixes and enhancements to the Sieve manage mode, to the Gravatar code and cleaned-up some very very old code. Also added the possibility to
set list-identifier as a group parameter.

Org-mode

I spent most of my time working on my jd/agenda-format branch, which is soon to be merged. I've also just got developer access to the Org-mode patch work and repository, so I'll be able to break things even more! ;-)

ERC

I fixed the bug that annoyed me for a long time. Now erc-track does not reset the last channel status on window visibility changes not made by the user.

Announcing Org-contacts

Tue, 08 Feb 2011 00:00:00 GMT

When I started to use Emacs, I got hooked by many stuff like Gnus and Org-mode. One thing I quickly started to hate is how the Lisp code can be old and unmaintained. That especially applies to BBDB, which has been unmaintained for years, and has very very very old and obsolete code.

Therefore I've decided to develop my own BBDB replacement based on my lovely Org-mode. It's called org-contacts, and it allows you to handle your contact like anything you would handle in Org. This way you can manage them the way you want, without any preset fields or any assumptions like BBDB has.

I had the chance to present it at the Paris OrgCamp a couple of weeks ago,
and due to the enthusiastic audience I had, I'm now releasing it to the wide
Internet.

Naquadah theme for Emacs

Mon, 31 Jan 2011 00:00:00 GMT

I often post Emacs screenshots on this blog, and consequently receive a bunch of request for my Emacs theme. Therefore I decided to publish it.

OrgCamp Paris 2011 review

Sun, 23 Jan 2011 00:00:00 GMT

Yesterday afternoon, I was at the first OrgCamp in Paris.

It was my first attendance to a BarCamp, and I really liked it. It's basically the first geek event I do not find boring nor useless.

There was about 18-20 persons participating, which was quite high, since we all initially though we would have been only 5.

We had several presentations of various features and personal usages of Org-mode. For my part, I've quickly presented the agenda, and my BBDB replacement named org-contacts (I'll probably talk about it on this blog in another post later).

The only downside was that Bastien (the new Org-mode maintainer) was not able to come and join us. On the other side, there were so much to tell for a first time, I did not have so much time to code. I only have been able to fix one bug reported during my agenda presentation.

In the end, the overall atmosphere was very enthusiastic and friendly, which was extremely pleasant. The #org-mode-fr IRC channel has been created on Freenode, following this event. Feel free to join us.

Since people liked it so badly, it seems there should be another barcamp in the next months. Stay tuned.

Code fontification with Gnus and Org-mode

Thu, 20 Jan 2011 00:00:00 GMT

I've added code fontification using Org src blocks inside Gnus.

This interprets the block as an Org buffer and fontify it accordingly if org-src-fontify-natively it set to t.

Thanks to Sébastien Vauban for the original idea and implementation. Now it works out of the box without any customization.

Color contrast correction

Tue, 23 Nov 2010 00:00:00 GMT

I finally took some time to finish my color contrast corrector.

It's now able to compare two colors and to tell if they are readable when used as foreground and background color for text rendering. If they are too close, the code corrects both colors so to they'll become distant enough to be readable.

To do that, it uses color coordinates in the CIE L_a_b* colorspace. This allows to determine the luminance difference between 2 colors very easily by comparing the L component of the coordinates. The default threshold used to determine readability based on luminance difference is 40 (on 100), which seems to give pretty good results so far.

Then it uses the CIE Delta E 2000 formula to obtain the distance between colors. A distance of 6 is considered to be enough for the colors to be distinctive in our case, but that can be adjusted anyway. That depends on reader's eyes.

If both the color and luminance distances are big enough, the color pair is considered readable when used upon each other.

If these criteria are not satisfied, the code simply tries to correct the color by adjusting the L (luminance) component of the colors so their difference is 40. Optionally, the background color can be fixed so only the foreground color would be adjusted; this is especially handy when the color background is not provided by any external style, but it the screen one (like the Emacs frame background in my case).

Here is an example result generated over 10 pairs of random colors. Left colors are randomly generated, and right colors are the corrected one.

<table style="border-collapse: collapse; width: 100%; font-family: monospace; font-size: 0.85em;"> <thead> <tr><th style="text-align: left; padding: 6px 10px;">Original</th><th></th><th style="text-align: left; padding: 6px 10px;">Corrected</th></tr> </thead> <tbody> <tr> <td style="padding: 6px 10px; background-color: #698b69; color: #ababab;">DarkSeaGreen4 / gray67</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #4a6b4b; color: #cccccc;">#4a6b4b / #cccccc</td> </tr> <tr> <td style="padding: 6px 10px; background-color: #6c7b8b; color: #228b22;">SlateGray4 / forest green</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #9faec0; color: #005700;">#9faec0 / #005700</td> </tr> <tr> <td style="padding: 6px 10px; background-color: #212121; color: #5c5c5c;">grey13 / grey36</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #131313; color: #6c6c6c;">#131313 / #6c6c6c</td> </tr> <tr> <td style="padding: 6px 10px; background-color: #9f79ee; color: #f0fff0;">MediumPurple2 / honeydew</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #9e78ed; color: #f0fff0;">#9e78ed / #f0fff0</td> </tr> <tr> <td style="padding: 6px 10px; background-color: #6e6e6e; color: #66cd00;">grey43 / chartreuse3</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #5e5e5e; color: #79de25;">#5e5e5e / #79de25</td> </tr> <tr> <td style="padding: 6px 10px; background-color: #faf0e6; color: #ee1289;">linen / DeepPink2</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #faf0e6; color: #ee1289;">linen / DeepPink2</td> </tr> <tr> <td style="padding: 6px 10px; background-color: #53868b; color: #0000ff;">CadetBlue4 / blue1</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #6c9fa4; color: #0000e1;">#6c9fa4 / #0000e1</td> </tr> <tr> <td style="padding: 6px 10px; background-color: #545454; color: #cdb38b;">gray33 / NavajoWhite3</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #525252; color: #cfb58c;">#525252 / #cfb58c</td> </tr> <tr> <td style="padding: 6px 10px; background-color: #7fff00; color: #cd9b9b;">chartreuse1 / RosyBrown3</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #9cff38; color: #b28282;">#9cff38 / #b28282</td> </tr> <tr> <td style="padding: 6px 10px; background-color: #c71585; color: #ff1493;">medium violet red / DeepPink1</td> <td style="padding: 6px 10px;">→</td> <td style="padding: 6px 10px; background-color: #9c0060; color: #ff55b9;">#9c0060 / #ff55b9</td> </tr> </tbody> </table>

All this has been written in Emacs Lisp. The code is now available in Gnus (and therefore in Emacs 24) in the packages color-lab and shr-color.

A future work would be to add support for colour blindness.

As a side note, several people pointed me at the WCAG formulas to determine luminance and contrast ratio. These are probably good criteria to choose your color when designing a user interface. However, they are not enough to determine if displayed color will be readable. This means you can use them if you are a designer, but IMHO they are pretty weak for detecting and correcting colors you did not choose.

Elisp color manipulation routines

Sat, 20 Nov 2010 00:00:00 GMT

Last week, I spent some time implementing various color manipulation routines. The ultimate goal was to find a way to determine if a text in a certain color was readable on a background with a different color.

Something I failed to do so far, despite my research in the area.

However, since I think my code could be useful for other people, I've set up a tiny git repository with the routines I wrote.

The funniest one to implement was CIEDE2000. I verified my code with the data given in the specifications and can assure it's correct. :-)

Org-mode and holidays

Mon, 15 Nov 2010 00:00:00 GMT

Org-mode has a nice option which allows you to show week-end days in a different color in your agenda. That means that Saturday and Sunday (when I do not work) are fontified with org-agenda-date-weekend.

But there are other days I do not work, like my vacations or holidays.

Therefore, I've wrote a patch to add org-agenda-day-face-function which is optionally called to determine what should be the face used to fontify a day. This allows me to use the same face for holidays and for week-end days, like for last Thursday which was an holiday in France.

That patch has been merged in Org last week.

Google Maps for Emacs: moving, caching and home

Mon, 08 Nov 2010 00:00:00 GMT

Last week, I worked on my Google Maps for Emacs extension. I've introduced a new format handling for locations which include the longitude and latitude. The initial format was just a string describing the location, which was obviously too limited.

It now prints coordinates of the different elements when the mouse is over the map, with other information.

It also center the map on M-x google-maps and set a default zoom level. This is something which was not set because it's not a good idea to set center coordinates in order to see all points on the map automatically. But you can still remove the centering by pressing "C". On the other hand, setting it automatically allows to move the map easily, and I think that what most users want to do.

I've also added a "place my home on the map" feature, accessible by pressing h on any map. That adds a marker according to the location set in Emacs using the calendar- variables.

This feature is also available under Org by pressing C-u C-c M-l, which shows the location of your appointment with your home on the map too.

Finally, you also get caching so it does not request images you already seen, which makes the moving nicer and faster to use, and prompt history.

Icon category support in Org-mode

Thu, 04 Nov 2010 00:00:00 GMT

My latest patch for Org mode has been accepted by Carsten today. It adds support for custom category icons in all views, like agenda or todo.

You just need to configure org-agenda-category-icon-alist and it will work out of the box.

Transparent GIF support in Emacs 24

Tue, 02 Nov 2010 00:00:00 GMT

Last week, I wrote a couple of patches to add support for transparency when Emacs is displaying GIF images.

Until now, it was displaying the color used to define transparency in the file data. Now it displays the image correctly by using the frame color as the transparency color, like it's done for other image formats.

The patches have not been merged yet, but will probably be soon.

No more dashes in Emacs 24 mode-line

Wed, 20 Oct 2010 00:00:00 GMT

We all know the good old Emacs mode-line you got under every window. Since the beginning (a long time ago), it starts and ends with dashes. I've proposed a patch to remove them.

Before:

After:

This has been merged in Emacs 24. You won't see any more ugly dashes in graphical mode.

Enhancing Emacs mouse avoidance

Tue, 19 Oct 2010 00:00:00 GMT

Recent Emacs versions have a wonderful capacity to hide the mouse pointer as soon as you type and insert characters in a buffer. This is controlled by the make-pointer-invisible variable, which is set to t by default.

However that does not hide the pointer when simply moving the cursor on screen. Therefore, I've started to use mouse-avoidance-mode, which make the mouse pointer jump if your cursor hits it.

Unfortunately, if your cursor hits the invisible mouse pointer, mouse-avoidance-mode makes it jump too, because it does not know it is invisible.

Well, it did not know. Now it does, thanks to my patches which have been merged in Emacs 24. Using the new function frame-pointer-invisible-p, one can know if the mouse pointer has been hidden by Emacs. Therefore I enhanced `mouse-avoidance-mode' to use it, and everything is alright now. :-)

Gnus and Gravatar support

Sat, 25 Sep 2010 00:00:00 GMT

This last couple of days I've been dedicated making Gnus… fresher.

I've decided to give a whirl on Gravatar support. I already tried the gravatar.el lying on the Interweb, but well, it was crap: it used wget to fetch pictures, therefore was totally synchronous. Reading each mail was slower. The cache did not even have TTL, as far as I recall.

So, I've now wrote gravatar.el implementing the Gravatar API. Asynchronously of course. With cache, TTL, etc. Perfect. :-)

Then I've composed gnus-gravatar.el, implementing a washing function adding Gravatar for From field and/or Cc/To fields, like done for picons.

As I was expecting, the patch was badly received by the GNU guys, which start talking about thinks like external resources, privacy, non-free software, etc. Boring.

Fortunately, Lars allowed me to push the patch in git so everybody can give it a try. I'm now waiting for feedbacks in order to know if I will have to maintain this patch outside Gnus, or not.

Here's the mandatory screenshot.

Gnus news is good news!

Thu, 23 Sep 2010 00:00:00 GMT

As I already wrote too many times, I've started to use Gnus 6 months ago, and never looked back.

At that time, I joined the ding mailing list in order to ask some dumb questions and, once, send a patch. There were very low activity on that list.

Until Lars, the original Gnus author, came back.

Three weeks ago, he started to wrote a new wash function to render HTML mails properly, with pictures. It's named gnus-html, and is (for now) based on w3m (but not on emacs-w3m, which is not part of Emacs).

Last week, I've sent a set of patches to replace the usage of curl by the standard url-retrieve function to fetch images, plus various enhancement. It seems that my work was good enough that Lars offered me write access to the git repository. I can therefore mess up the Gnus entirely. Hurrah!

I've continued to work on gnus-html and recently merged a set of patches improving image retrieval (which is now done in parallel) and starting to use url-cache to cache image for a defined period of time. Of course, I found a bunch of tiny bug and special case while reading RSS feeds and various HTML mails, and fixed them all along.

Lars added a libxml binding for Emacs 24, providing the html-parse-string function. His future plan seems to be the abandon of w3m in favor of a native parsing via libxml to render HTML, and therefore, HTML mails.

I should also mention the new nnimap back-end; Gnus has been designed to read NNTP newsgroups, and not mails. Consequently, it had a very poor behaviour when used with a back-end such has IMAP.

Lars took a week to rewrite entirely our dear nnimap back-end, and make it act in a more expected way. There's still a bunch of bug and code to write, but it is at least usable and seems faster than the old code.

Last thing I did was to rewrite the icon support in the group buffer. When I started to use Gnus, I was curious and tried to configure this. I never managed to make it work, and now know and understand why it was broken. So I ended rewriting entirely, and now it works. I never though I would understand, fix, and commit this code when reading the Gnus documentation this winter, but hell yeah, I did.

Now I've still several little project to improve things in all sort of area.
We'll see what I'll do next. :-)

Emacs, Org, whatever the weather!

Wed, 08 Sep 2010 00:00:00 GMT

Another week, another Emacs extension!

I had (once again) a wonderful idea: what if I could have the weather forecasts in my Org agenda? Wouldn't that be wonderful?

My quest started by looking for a service offering a good weather forecast API. I found nothing simple as the hidden Google Weather API, which is nice, but… not documented. Not at all. Not a single line. Nah.

Then, I wrote a google-weather extension, implementing a basic Emacs Lisp API to retrieve data from the Google service:

ELISP> (google-weather-data->forecast (google-weather-get-data "Paris"))
(((9 8 2010)
  (low "53")
  (high "63")
  (icon "http://www.google.com/ig/images/weather/rain.gif")
  (condition "Rain"))
 ((9 9 2010)
  (low "53")
  (high "69")
  (icon "http://www.google.com/ig/images/weather/chance_of_rain.gif")
  (condition "Scattered Showers"))
 ((9 10 2010)
  (low "54")
  (high "72")
  (icon "http://www.google.com/ig/images/weather/partly_cloudy.gif")
  (condition "Partly Cloudy"))
 ((9 11 2010)
  (low "55")
  (high "75")
  (icon "http://www.google.com/ig/images/weather/partly_cloudy.gif")
  (condition "Partly Cloudy")))

My API even implements data caching, which is nice to speed up the agenda display.

By the way, I think my next job will be to hack on the url-cache feature of Emacs, which is utterly buggy and has probably never be used. But that's another topic.

Finally, I just had to write another module on top of that to export the forecasts to Org. A screen shot is probably better than a long and boring explanation, so here's the result.

My only regret is that the icons provided by Google are ugly squares, so I did not want to use them. On the other hand, I did not found any icon set that would have all the icons Google provides (around 20). So I felt back on the icon naming specification to map the Google images to standard images. Any better idea would be welcome, of course.

All the information can be found on the Google Weather for Emacs extension homepage.

Emacs and OfflineIMAP

Fri, 03 Sep 2010 00:00:00 GMT

I recently decided to use OfflineIMAP to synchronize my mails on my laptop. It's a great piece of software, and allows me to read my mail while I'm offline.

I use it with Gnus, of course. But I lacked a proper way to integrate OfflineIMAP with it, so I decided to write a little Emacs extension to run and monitor OfflineIMAP directly from Emacs.

Here comes offlineimap.el, an Emacs extension to run OfflineIMAP directly within Emacs. It will display OfflineIMAP output in a buffer, and optionally shows the current OfflineIMAP operation in the mode line.

By default the status is in the mode line only if you are in the Gnus group buffer. But that's customizable, of course, since this is Emacs!

If you are using el-get, there's already a recipe to install it!

Emacs, Google Maps and BBDB

Wed, 18 Aug 2010 00:00:00 GMT

Today's fun idea was to put all my contacts stored into BBDB on a Google Maps' map, using my Google Maps extension for Emacs.

With the help of a few lines of Lisp glue:

(google-maps-static-show
 :markers
 (mapcar
  (lambda (address-entry)
    `((,(concat
         (mapconcat
          'identity
          (elt address-entry 1) ", ") ", "
          (elt address-entry 2) ", "
          (elt address-entry 3) ", "
          (elt address-entry 4) ", "
          (elt address-entry 5)))))
  (mapcan
   (lambda (record)
     ;; We need to copy the returned list, because mapcan will modify it later
     (copy-list (bbdb-record-addresses record)))
   (bbdb-records))))

It's really simplistic, but I did not need more to have fun. :-) This could be extended to set a specific marker and/or color for each contact, with a legend. I'll let that as an exercise for my readers.

Update on rainbow-mode

Tue, 10 Aug 2010 00:00:00 GMT

rainbow-mode had a big success and good feedbacks when I released it for the first time a couple of months ago.

Several users asked to me request its inclusion into Emacs. Therefore, some days ago, I proposed to merge it inside Emacs trunk. My request has been denied, but the mode has been added to the Emacs 24 package repository.

In the mean time, I've added support for hsl() and hsla() support, and added
CSS 3/SVG color names.

M-x google-maps

Mon, 28 Jun 2010 00:00:00 GMT

Since I have started to use Org-mode, I though it was missing something to have appointment locations on a map. Of course, it's easy to get a LOCATION property from an entry, and then browse-url on Google Maps.

But it is too easy for me, so once again I said: challenge accepted! I will bring Google Maps into Emacs!

After several hours of work, the google-maps.el project shows a map!

It fully implements the Google Static Maps API and the Google Maps Geocoding API.

You can type M-x google-maps and type some place to see it marked on map. Of course you can do much more, as seen in the screen shot above.

I've also completed all of this with a small org-location-google-maps.el which simply show a Google Maps' map for the location of an event in Org mode by pressing C-c M-l in an Org buffer or in the Org agenda.

Announcing rainbow-mode

Wed, 16 Jun 2010 00:00:00 GMT

While customizing Emacs this last weeks, I had the need to customize also the color theme.

Color themes are always a pain in the ass to edit, because you're supposed to read color strings like #aabbcc and guess what colors they represent.

This is why I wrote rainbow-mode, a minor mode for Emacs that will highlight strings that represents color, using the color they represent.

This support hexadecimal syntax, HTML color name, X color names and rgb() CSS syntax.

Desktop notification support for Emacs

Wed, 09 Jun 2010 00:00:00 GMT

This last weeks, I've worked on implementing the Desktop Notification Specification into Emacs.

It allows sending desktop notification in a very simple way.

(notifications-notify
    :title "You've got mail!"
    :body "There's 34 mails unread"
    :app-icon "~/.emacs.d/icons/mail.png"
    :urgency 'low)

It supports the protocol signals (NotificationClosed and ActionInvoked) and the two main methods (Notify and CloseNotification).

The methods specification are implemented entirely (hints, replaces, actions, icon, etc).

The signals are supported via callbacks function provided on the notification creation.

It have been merged into Emacs trunk today.

2010-06-09  Julien Danjou  <julien@danjou.info>

	* net/notifications.el: New file.

This also allowed me to discover, raise and fix a bug in the D-Bus binding of Emacs, which will be probably fixed in trunk soon.

Announcing erc-track-score

Mon, 07 Jun 2010 00:00:00 GMT

A couple of months ago, I've started using ERC to hang out on IRC.

I've read all the pages on EmacsWiki about it, just to see how far I could customize it.

I must admit that I was not disappointed, even if I expected to be. It's quite a nice software, and once well configured it's more convenient that my old irssi setup.

While browsing EmacsWiki, I read an interesting idea about channel scoring/temperature on the erc-track page. The idea is to see if it's worth jumping to an IRC channel to see what people are talking about.

Challenge accepted!

I sat up and started to dig though ERC source code to find the information I needed about variables and functions.

I finally did write something nice, which I called erc-track-score. And yet another piece of software I wrote for my lovely Emacs!

How does it work? Ha-ha, I was sure you would ask. You're so predictable, dude! Read the following, and you'll know everything you ever wanted to know about it since the moment you read the title of that blog entry.

Which probably turned you on.

Nasty you.

First of all, the score of a channel starts at zero. Zero means "seriously, don't bother, nothing is happening here".

Upon each new message arrival, the score is incremented by 1. If a new message contains a keyword, your nickname or is sent by a pal, the score is increased by configurable values, by default between 2 and 20 points, depending on the match type. On the other hand, when a message is send by some fool, the score is decreased by 1 by default.

Obviously, if the score is going negative, you really should not jump to the channel.

Finally, the score is permanently and slowly brought back to 0. By default, the score is decreased by 1 point every 10 seconds.

Overall, reading the score should gives you a good idea of the channel temperature.

I'm still not sure what is the best formula to compute the score, but so far the default values seem quite good. We'll see.

Announcing muse-blog

Wed, 19 May 2010 00:00:00 GMT

Digging into the fabulous world of Emacs and Lisp, I wanted to use it to build my personal Web site and my blog.

I already moved from ikiwiki to Emacs Muse for my HTML pages some weeks ago.

Muse provides an extension to maintain a journal, called muse-journal. Unfortunately, it was far to fulfill all my needs, and I decided that it would be a good exercise to write a better extension.

Consequently, I started to wrote my own extension, which I named muse-blog.

And this is now what is used to build this blog. :-)

Entering the Emacs world

Mon, 17 May 2010 00:00:00 GMT

In February 2009, my friend dim tried to force me using Emacs. I know a couple of people using it and Gnus for reading their mail, and it always made me curious.

At that time, more than a year ago, Emacs 22 and Gnus did not seem usable from my point of view.

But around mid February, with the help of dim, I tried again to start using Emacs.

Actually, this was not something new for me. I (very basically) used Emacs between 2000 and 2006. In 2006, when I finished the university and started working at Easter-eggs, I met a couple of vim enthusiasts. They taught me how to use it in various ways, and I started to know more about vim than Emacs, so I switched.

This time, I started by configuring it, but reading the manual and also learning a bit of Lisp. It took me several weeks, but step by step I learned many, many things. And I must admit, I liked it.

I've configured and starting to use some very important mode, like Gnus, Org mode, Muse, or even ERC.

I'll probably talk about various Emacs related things in the near future, since I already wrote more than a thousand lines of Lisp in the last 2 months.

Anyhow, I'd just conclude by asserting that my new Emacs/Gnus/Org/ERC setup beats my old vim/mutt/nothing/irssi to the death with a baseball bat. :-)