EmacsWiki: Categorizing Information Manager (original) (raw)

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:

• ee-buffers - display and manipulate Emacs buffers
• ee-windows - display and switch Emacs window configurations
• ee-menubar - categorized access to Emacs MenuBar
• ee-commands - categorized menu of Emacs commands
• ee-processes - display and manipulate Emacs processes
• ee-history - display lists from Emacs history variables
• ee-customize - browse Emacs customization groups
• ee-info - browse Info documentation
• ee-finder - keyword-based Emacs code finder
• ee-tags - etags facility
• ee-imenu - categorized mode-specific buffer indexes
• ee-outline - manipulate outlines collected from outline-mode
• ee-marks - display and go to marked lines in the current Emacs buffer
• ee-gnus - summary and topic mode for Gnus
• ee-bbdb - summary mode for BBDB
• ee-edb - summary mode for EDB
• ee-ps - display CPU processes
• ee-dired - categorized directory listings
• ee-programs - categorized program menu
• ee-dselect - Debian package handling frontend
• ee-datafile - display and edit data files
• ee-textfile - organize information from text files
• ee-fields - display and edit fields of the current record
• ee-views - display, edit and switch views

You can get it here:

• http://www.jurta.org/emacs/ee/

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

Screenshots

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

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

XEmacs

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 () (save-excursion (end-of-line) (point)))

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

Discussion

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 http://www.jurta.org/emacs/ee/programs.en.html 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.

• As it seems to be the idea to represent data in some kind of hierarchical (tree-like) fashion using a table as the main datastructure doesn’t really well fit to the adressed problem. @Juri: Just in case you haven’t ever tried it before storing hierarchical data in a relational database poses a multiplicity of problems reaching from handling foreign-key constrains to maintain data integrity to data-modeling as a whole.
• From a mathematical point of view first-order-predicate-logic lying at the base of any relational data model provable doesn’t posess enough expressiveness to even formulate queries for questions like that of ancestry that might be extremely interesting - especially if the main purpose is to work with hierarchical data.
• Proven in this case means mathematically proven, so how cleverly you’ll ever try to implement you won’t be able to answer the probably most interesting an as such most frequent questions without iterating over your data over and over again.
• Last but not least even though there is some support for arrays as well elisp is rather tailored to work perfectly well with nested lists which in turn are nothing else than trees in disguise fitting the hierarchichal approach taken to display data more than well. (A (B C D) E () (F G)) as an example already forms a perfectly well tree without any need for (“root” …) elements and deeply nested (_s … (_r …. (_a .. elements as spotted in your view-atree implementation.
• Thinking a bit longer about it, I even doubt the idea of using a separate datastructure to represent “real” data and rewriting the whole buffer instead of just using the buffer contents itself as data source seems to be too clever at all.
• As the buffer contents itself poses some kind of an array like datastructure it won’t come up to my mind why I should tranfsform data given in an in-memory table to some kind of hierarchichal data-model in the first place just to afterwards flatten it out again. At least to me this doesn’t look like making a needless time-consuming compution once but even twice.

@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

CategoryPersonalInformationManager