Emacs Non-Flickering Patch

Earlier today, Daniel Colascione merged his double-buffering Emacs display patch, and I was interested in seeing whether it reduced flickering when viewing animated GIFs on my problematic main machine.

And it sure does:

First you see an Emacs from five hours ago displaying a GIF, and it is flicker-o-rama.  Then I switch to a brand new Emacs with Daniel’s patch, and it is completely flicker-free.

Now, that the flicker was there in the first place is probably due to me not bothering to figure out what settings the Nvidia driver needs to … work better: On my laptop, there was no flickering even without Daniel’s fix.  So your mileage will vary, but it’s obviosly a major step forward, flicker wise, on some machines.  Thanks, Daniel.

Emacs Imgur Interface

It was suggested on github that the Emacs meme creator should offer uploading images to imgur (and return the resulting URL) for max magic.  That seems extremely true.

There is already an imgur.el on github, but it’s doesn’t seem ideal (it does much more than just uploading; it seems to be using an older API; it relies on external programs; and most seriously: it wasn’t written by me), so I wrote a new one.

(For convenience, I’ve included the imgur.el in the meme repository, too.)

Kudos to the imgur people for creating such an easy API for uploading images.  It literally took 15 minutes to write imgur.el.  Literally!


An Emacs Meme Generator

I got an idea tonight: Emacs must have a meme generator.  Using a web browser seems so jejune.

After pondering a few minutes and then typing a few hours, here it is.  And here’s how it looks in action:

It basically just manipulates an SVG image, so it’s less work than you’d expect.

If you want to play around with it, you need a very fresh Emacs trunk; see this for easy installation instructions.  You also need the Impact font from the Microsoft font collection; in Debian it’s installed by saying

apt-get install ttf-mscorefonts-installer

Uhm…  I think that’s basically it.


Emacs Bug Trends

I had cold recently (well, I still have), so I amused myself by going through the Emacs bugs database and fixing documentation related bug reports.  Should be safe enough to do even with a fever.

Anyway, I started wondering: Are things getting better or are things getting worse?  The Emacs bug statistics charts aren’t really all that helpful:

Emacs bugs over the past year

Uhm…  there’s a pixel more in January…  and then one less in February…  and then…  er…

So I wrote a little thing to download the debbugs database and used a JS library to plot the data. (You can examine a “live” version here with zooming and stuff.)


OK, things are getting worse.  Apart from the discontinuities in the chart (all four of them from when Glenn Morris and I have been doing bug triages and closing outdated bug reports), Emacs is gaining about two unclosed bug reports per day.

(And don’t look too closely at the data from the last couple of months.  It turns out that the debbugs database doesn’t have a data field for closure dates, but only a “last modified” thing, and closed bugs are archived after one month.  So I transposed that date a month into the past for older bugs, but that left March without any closed bugs, so I randomly distributed closures from April to March, and in April there was more bug triaging going on, and aaaargh.)

But what about if we exclude all the wishlist items?  After all, those aren’t bugs…


Not really much of a difference.  But does the unclosed rate depend on people reporting more bugs or the maintainers not fixing the bugs?


Nope, the reporting rate is amazingly linear.  It’s the rate of closures that veers…

Looking more closely at the data, the top ten bug closers (and I’m not including the “technical closers”) are responsible for 70% of bug closures.  They’re doing an awesome job, day in day out.  It’s something I certainly couldn’t do on such a consistent basis.  But still, more people are needed…

I wondered about why that almost-two-year-stretch of flat bug reports ended in the start of 2013, and I think that’s explained by Chong Yidong stepping down as co-maintainer.  He totally slew at fixing bugs, the data seems to suggest.

In conclusion: Emacs needs more people to help out with bugs.


Bugs in the Skies

I was wondering how hard it would be to make the Emacs interface to the Emacs bug tracker offline capable. And it turns out it’s not very hard at all to create a half-assed solution here.

Basically you just have to download the bug list, and then all the bugs (which are just mbox files), and then there you are.  All control messages go via email, and Gnus is already offline capable, so here I am sitting on the plane from Sydney doing some bug triage:

IMG_20160301_1718273Unfortunately, food arrived after I’d done five bugs, and I had some wine, and then I fell asleep.


A Big Patch For Emacs, A Small Step For eww

During my summer holiday I’ve mainly been working on making the Emacs networking layer more asynchronous.

To set up a connection, you first have to do DNS resolution, then the TCP three way handshake to set up a socket, and then (if you’re setting up a TLS connection) do the TLS negotiation.  Then you can start talking to the server.  Up until now, only the middle bit (setting up the socket) has been non-blocking, while the two bits at either end have blocked the main Emacs execution thread.

This means that when eww, the Emacs web browser, wants to download and insert an image into the buffer, the user experience got kinda choppy.  The DNS resolution might take a while, and when talking to far away servers, the TLS negotiation certainly took some time.

By adding code based on the glibc getaddrinfo_a library function, the first problem was solved.  By calling the gnutls negotiation code from the Emacs event loop, the final problem was solved.

Behold!  I’m here reloading a Norwegian web page where most of the images are fetched via https (i.e., TLS):

I’m in Australia, so the networking all the way to Norway is s-l-o-w.  Especially since these are TLS connections.  Lots of chatter back and forth.  As you can see from the cursor movement, there’s no noticable choppiness.  Trying the same on this web page before the async patch went it is pretty horrible.

Yay.  And it was only a 3200 line diff. Ok, ok, most of that was chopping up lots of 700 line functions into slightly less ridiculously long functions, but eek.