No, I'm not talking about git support, anyone knows Emacs is better at git than git itself. I'm referring to moving the codebase from bzr to git. At the moment, this is planned to happen on November 11, and a cheerful day that will be.

In the words of Eric S. Raymond,

The bzr version control system is dying; by most measures it is already moribund. The dev list has flat-lined, most of Canonical's in-house projects have abandoned bzr for git, and one of its senior developers has written a remarkably candid assessment of why bzr failed[.]

I'm not an expert on bzr, but I've noticed it discourages some new contributors. Ultimately, adopting a system people already tend to be familiar with is a big step in the right direction.

Dynamically loading libraries is a big deal, and it's closer than ever. Some very inspiring results has been reported in the last month and, while there are still some obstacles under discussion, it's looking almost in shape for release.

Of course, not every package needs this—in fact, the vast majority doesn't. But this would be a huge boon to a number of packages which, so far, have had to resort to sub-processes or resign to elisp.

This is not a new idea in any way but it's become increasingly urgent with the growth of the package repositories. I'll be honest, I haven't seen much talk about this feature. Still, sometime next year, if there's no sign whatsoever of concurrency being a thing, I'll write a hack for it work with package.el. Here's why I think that's important.

Consider this situation a little more than a year ago. I noticed my laptop was taking a while to display the *Packages* buffer. “No doubt,” I thought to myself, “1477 packages is a bit much for this laptop. No worries though, 5 seconds of waiting isn't that bad.”.

Fast-forward fifteen months. I invoke M-x list-packages, wait 20 seconds, and the buffer I'm given crosses the 3000 lines threshold. That's partially aggravated by the fact that package.el displays separate entries for each repository a package can be found in. But even if we eliminate these redundancies, since July 2013 one thousand unique new packages have been released. That is an impressive rate of over 2 new packages every single day.

Now consider that this rate shows absolutely no sign of diminishing. Worse yet, consider that the rate in which packages are updated on Melpa is almost two orders of magnitude higher. Where will we be by the time Emacs 25 is released?

Gradually and surely, the time it takes to upgrade one's Emacs packages will surpass that of updating one's Operating System. And what are we to do in the mean time? Play Minesweeper?

We need asynchronicity, now more than ever, because the *Packages* buffer plays one of the most fundamental roles in the expansion of the community. We need a package manager that checks for new releases in the background while we navigate the previously cached list, and one that performs updates in the background without forcing us to go for a coffee.

This is an extension to the previous topic. Sluggishness is not the only consequence of an ever-increasing package menu. Navigating the menu in its current form is akin to exploring the Amazon rain-forest. There's plenty of dazzling richness to be found, but the sheer size and roughness are overwhelming—not mention the piranhas.

Emacs 24.4 introduces keyword filtering to the menu, and Paradox offers a couple other forms of filtering, but they're still very crude. We need a navigable tree of categories—which would to facilitate discovery for times when isearch is a bit too narrow. And we need a simple and honest search box, even if its only purpose is to invoke something similar to occur.

The customize interface is powerful and beautiful. Its major achievement, in my opinion, is to make it Emacs customization accessible even for those who know no elisp at all. When correctly configured, I could see my grandmother using it.

Still, it is for that same reason that we must not admit it to have recurring bugs. A sizeable part of its user base might never be aware that they're running into a bug, they'll just think “Emacs is complicated”. So it doesn't help, you see, that it has a couple of issues so deep-seated that even experienced lispers might be led to think they're doing something wrong.

There have been talks of fixing this on the dev list, so I'm optimistic.

I could go on about this for several posts. Plain and simple: Emacs doesn't have namespaces, so we have to prepend the package name or prefix to every single defined symbol. Here's a snippet of what that looks like:

(defun package-initialize (&optional no-activate)
  "[DOC]"
  (interactive)
  (setq package-alist nil)
  (package-load-all-descriptors)
  (package-read-all-archive-contents)
  (unless no-activate
    (dolist (elt package-alist)
      (package-activate (car elt))))
  (setq package--initialized t))

I'm sure you see how that's annoying to write and read. Not to mention every symbol is permanently available in the global namespace.

There have been talks of implementing a system similar to common-lisp packages, which takes a lot of adaptation to how symbols are interned. While we wait, I wrote a namespacing engine in the form of a macro. Which turns the above into something like this.

(define-namespace package- 
(defun initialize (&optional no-activate)
  "[DOC]"
  (interactive)
  (setq alist nil)
  (load-all-descriptors)
  (read-all-archive-contents)
  (unless no-activate
    (dolist (elt alist)
      (activate (car elt))))
  (setq -initialized t))
)

One way or the other, some form of solution should make its way into Emacs. And I'll fight for that to happen before 25.

That's my list of most immediate improvements. Did I miss something big? Do you feel insulted and disagree aggressively, or do you feel enlightened and praise such accuracy?

May the year to come be filled with parentheses.