Ee is the categorizing information manager for Emacs. It works by collecting information from different sources and converting information to a relational or associative database. It uses the fields of database table records to build the category trees, which are displayed in the Emacs view buffer. The rules for creating the views are also specified by similar data structures and include the rules for building category paths, sorting records and categories, calculating the totals of category fields, filtering records, and printing category tree and record lines.

The list of available ee extensions:

You can get it here:

The exact purpose of ee is to represent data by different tree views (outlines) and to allow to manipulate data by operating on displayed tree views (expand/collapse outlines, mark and delete data, create new data records, change field values of existing records, call functions on selected data record or group of records, etc.) Ee has a separate database for describing how different views are created from data. Since data processed by ee is arbitrary, so ee could be used as an “indexer” for other Emacs packages. In this case ee knows how to extract and update data from other Emacs packages. The main advantage of ee is a simple and uniform interface for displaying and manipulating any kind of data.

The core of ee is just the display and database engine: simple, but flexible. So such kind of application as gnome dashboard can be easily implemented as ee extension. – JuriLinkov


Use M-x ee to get the list of extensions available (categorized, of course). Choose ee-ps:

Showing the list of extensions available

Mark two processes for deletion using ‘d’ and then kill them using ‘x’:

Showing the list of processes and marking two for killing


I developed it under GNU Emacs and have not yet ported it to XEmacs. If you are interested in such a port, could you contribute? – JuriLinkov

I added the following:

(require 'overlay)
(defun line-end-position ()

I had to comment out two lines in ee-buffers.el where we call (buffer-display-time) and (buffer-display-count), as they are not available in XEmacs. Now I have to learn how to use ee :-) before I can find out if anything else needs to be done – AlainMellan

You can use point-at-bol/point-at-eol instead of line-beginning-position/line-end-position if you want to be compatible. Emacs defines these aliases for this purpose.

I’ll create new file ee-xemacs.el with this code for the next release. But I wonder why every package I’ve seen reimplement the same compatibility code? Why doesn’t exist some standard package which handles compatibility issues between GNU Emacs and XEmacs? But maybe such a package already exist? Does anybody know about this? – JuriLinkov

I’ve found a package fsf-compat that should do the trick. In addition to (require ‘overlay), we need a (require ‘goto-addr) and we don’t need to define (line-end-position), but I haven’t found anything for (buffer-display-time). – AlainMellan

It is very good that such compatibility package exists! You can try to use it on other extensions too and set buffer-display-time to nil and buffer-display-count to 0. – JuriLinkov


I would love a more close merge between ee-dired and dired so that you could to the normal file/directory operations when in ee-dired mode. That way, Ci could completely switch from using Windows’ explorer.exe to dired. This package really has a lot of potential. – MathiasDahl

BTW, I’ve just looked at your MakeSmartShortcuts. It could be adapted to generate similar trees for which already works with Windows’ Start-Menu. – JuriLinkov

Awesome package! – AlexSchroeder

Fantastic! I love coming across pacakges like this; they really breathe new life into emacs by reminding us how extensible it is – Jesse Alama

Fix it !

In its current state this package doesn’t even seem to come close to be of any use at all. It sure makes a really nice mock-up but unfortunately its nothing more than exactly that. I’m really sorry to have to give it such a bad review, especially as it seems more than obvious that the author invested quite a lot of time and effort in it.

But after almost spending my whole day digging through the code I thought I’d better place a note of warning here. As it seems even if against my estimation the general idea of storing the data to be displayed in a relational database holds there still seems to be a lot of work and time to invest before the package will become useful at all.

As in most cases a one-size-fits-it-all approach doesn’t really turn out well, I’m not quite sure about it, but I think I fell a little bit in love with Juris idea of somehow managing a bunch of buffers dedicated to various actions in a more or less unified manner, so I sure hope he won’t give up. Nevertheless I think maybe even the basic concept might have to be revisited. For a whole couple of reasons listet below I’m quite unsure that putting a relational database as the ground to work upon doesn’t seem to be the right way to go.

@Juri: I hope by spelling out my view on the current state of your project I didn’t hurt or harm your feelings in any way, as this clearly wasn’t my intention at all. I hope by the time I invested to formulate my opinion will serve as a proof that I really like your idea and am quite sure you will move your package to a point where ee is not only usable but probably one of the most valuable packages in my emacs session.

Please don’t stop continuing your work on it as my remarks are nothing else but a fools ideas, who can’t await to see a finished version.

P.S.: As a last hint - Maybe you should try to concentrate on one part say ee-buffers or whatever you like the most and focus on it’s development before spreading out in all too many directions. You already seem to have gathered a lot more TODOs than anyone can handle at all, so probably even dropping some might be a good idea. – bspaeth

@bspaeth: Thanks for the feedback! In the current state the package is already usable, as I and many other users are putting it into heavy use every day. But of course I’m open for further improvements and I welcome more ideas. I see that you are focusing on the internals in your remarks. When fixing the internals, it’s important to not break the existing UI features, since the users may rely on their long-standing behavior. I agree that the current internal implementation is not the most efficient. It may cause significant slow-down when displaying very deep hierarchical views created from thousands of database records. I already invested a lot of effort to improve performance, but to be able to process millions of data records you have to invest more effort. Regarding the mathematical foundation, when I started to design this package 12 years ago, there was nothing like this, so I had to invent many concepts from scratch. Nowadays we see the development of several document-oriented NoSQL databases (like CouchDB, etc.) that implement many of my ideas of processing the documents with variable number of fields and building hierarchical views from them. For example, my package contains an implicit implementation of MapReduce, but at the time when I implemented this package 12 years ago there was no such commonly accepted concept as MapReduce, so I had to invent my own. You can see more similarities between my package and NoSQL databases. Currently NoSQL databases are quickly developing by adding new features and improving their performance. Unfortunately I have no resources to compete with them alone. – JuriLinkov