emacs-fu

I few months ago, I introduced mu4e, a modest little emacs mail client that I wrote. It seems many people picked it up, great!

what's new?

dynamic folders

(setq mu4e-trash-folder "/trash")

(setq mu4e-trash-folder
 (lambda (msg)
 (if (and msg ;; msg may be nil
 (mu4e-message-contact-field-matches msg :to "me@work.com"))
 "/trash-work"
 "/trash")))

refiling

(setq mu4e-refile-folder
 (lambda (msg)
 (cond
 ;; messages to the mu mailing list go to the /mu folder
 ((mu4e-message-contact-field-matches msg :to
 "mu-discuss@googlegroups.com")
 "/mu")
 ;; messages sent directly to me go to /archive
 ;; also `mu4e-user-mail-address-regexp' can be used
 ((mu4e-message-contact-field-matches msg :to "me@example.com")
 "/private")
 ;; messages with football or soccer in the subject go to /football
 ((string-match "football\\|soccer" (or (mu4e-message-field msg :subject) ""))
 "/football")
 ;; everything else goes to /archive
 ;; important to have a catch-all at the end!
 (t "/archive"))))

crypto support

so…

background

how does it work?

trying mu4e

a small tour

parting thoughts

I'm a fairly busy person, and need to keep track of a lot of things. That includes following a bunch of internal IRC channels, attending meetings, meeting deadlines and so on. But I don't want to stare at my org-mode calendar, or flip through ERC buffers all the time.

Instead, I'd like to have one little emacs frame (window) that gathers these ('events'), and transfers me to wherever the event came from when I click it - some IRC-channel in ERC, my org-calendar etc. and other inputs. Note, using Bitlbee, you can include Facebook-contacts, GoogleTalk-buddies and Twitter-tweets, … in ERC - so, you can track just about anything.

In addition, with so many inputs, I'd also like the possibility to filter out unwanted events, and generate various light/sound effects and fireworks, proportional to the priority of the event.

For all this, I wrote a little emacs-tool called Sauron that does just that. M-x sauron-start pops up a frame that receives events, and M-x sauron-stop hides it and stops listening. It works with ERC, org, and listens for D-Bus messages; so it's pretty easy to get events from all over the place.

It's a bit of a balancing act to get all the important information while not being swamped in noise, but Sauron allows you to fine-tune it to whatever works the best for you. I've tried to have sane defaults though, so things should mostly work without too much configuration - but if you need the power, it's there. I also added some convenience functions to make it easy to get sounds and other special effects.

So - it's brand new, it is of seems-to-work-for-me-quality, and I'd like to invite others to try it out, hack it, give feedback, add new back-ends and so on – what better Christmas present to ask for!

There's documentation, examples etc. to be found in Sauron's github repository.

Ages ago we discussed ELPA, the emacs packaging system. It allows you to
browse through an online repository of emacs packages and install, uninstall
and upgrade them, all from within the emacs comfort zone (menu:
Options/Manage Emacs Packages).

Emacs 24.1 (a pretest is available) will include a version of ELPA --
package.el; the version included with emacs 24 supports multiple
archives. The official archive is the one provided by GNU, then there is
the current one for ELPA, but there's now a third one available: Marmalade.

Marmelade ('Spreadable Elisp') offers a very easy way for developers to
make their packages available to emacs users, and an even easier way for
users to test out interesting packages.

To use all available package repositories (GNU, ELPA and Marmalade), add
the following snippet to your .emacs:

(setq package-archives '(("ELPA" . "http://tromey.com/elpa/") 
 ("gnu" . "http://elpa.gnu.org/packages/")
 ("marmalade" . "http://marmalade-repo.org/packages/")))

This works out-of-the-box for Emacs 24; for Emacs 23, you'll need the newer
package.el, which you can get from the emacs 24 repo (if necessary, remove
the old package.el first).

Currently, there are 870 packages listed in the three repositories – a lot of
toys to play with! In fact, it is already getting quite hard to find what
you're looking for; a bit more structured way (maybe using categories) would
be useful. Also, a bit more information than the one-line description would
be very useful.

Nevertheless, it's a great addition to emacs, which will make it much easier
to play with packages – without even having to read the installation
instructions.

One of the notable new features of emacs 23.2 was the inclusion of CEDET. CEDET adds IDE-type functionality to emacs, and one only needs to read the responses to the 100th post to see the great interest in that.

The man behind CEDET is Eric Ludlam (EML), a long-time Emacs user and developer. He kindly answered the many questions we had for him. Thanks, Eric!

EML: I manage a software engineering team at the MathWorks. The MathWorks are the creators of Matlab. In my spare time I maintain CEDET, the Matlab support for Emacs, and build replicas of ancient siege engines.

I've been building catapults of various types for use at the World Championship Punkin' Chunk since 1998. My team started with a traction trebuchet, then a HCW Trebuchet, then moved to Human Powered Centripetal, and finally to the torsion division with MistaBallista. As far as I know, Mista Ballista is the worlds largest farthest throwing currently functional ballista.

Most recently, I got to help demolish a building where I work by shooting stuff at it, which was a lot of fun.

EML: I've been hacking Emacs since version 18.54 on Ultrix because the alternative was vi. My first post (and thus contribution to Emacs) was to gnu.emacs.sources on June 6, 1992. I've used Emacs to work on C/C++ code for many years which inspired all the various parts of CEDET, but these days I don't get much coding time.

My work with Emacs and CEDET is seasonal currently. The summers are usually busy with family activities, and my falls are busy getting the catapult ready, so CEDET work usually happens in the winter.

EML: I started with some really basic editors and eventually with LSE (Language Sensitive Editor) on VMS. LSE was pretty cool. When I switched OSes to Ultrix and was forced to use Emacs, and discovered you could script it, I was hooked. My first big Emacs hack was etalk, an implementation of Unix talk in Emacs.

In one of the Emacs related newsgroups, a spoof story floated around about how Emacs became sentient, and started writing code for Richard [Stallman] instead of the other way around. Since then I've always wanted to get Emacs to start writing my code for me. I wrote cparse.el, a regexp nightmare that could parse almost any C file into a sequence of highly detailed tags. The tags could be used to then generate code, and I had a cool comment writing utility, automatic prototype generation, and some navigation features. On the whole it failed for many reasons.

The concept, however, continued. CParse became the basic idea behind what is now the Semantic package in CEDET, though none of the old stuff remains beyond some echos in some SRecode utilities.

My end goal is to provide round-trip code management in Emacs. Emacs needs to be able to read your code, allow you to perform transformations in the code in an abstract way, and then write new code for you. Everything in CEDET is building toward that goal. It is taking a long time, and you can see it starting to take shape. Semantic can parse the code, COGRE can manipulate UML diagrams representing your code, and you can export diagrams into code through SRecode. Unfortunately this isn't a round-trip solution as the generated code currently should not replace existing hand-written code.

EML: I maintain CEDET and field questions on the mailing list. There are several contributors who either own some tool in the "contrib" area, fix bugs, answer questions or apply patches for new features. There has always been someone to pick up the slack when I'm busy elsewhere, and I've greatly appreciated that.

The easiest (and most common) way to contribute code to CEDET is to provide support for some new language, or to create a language agnostic tool using the CEDET APIs. As with Emacs, you need to be able to assign copyright to the FSF to contribute to CEDET's core, but new language support or utilities can have a home in the contrib area as well.

EML: I've been providing assignments for the parts of CEDET since 1996 or so. For Emacs 23.1, CEDET was at a stable and useful enough state that Chong Yidong was willing to do the work to integrate it into Emacs. My ability to get a legal release for CEDET in time for Emacs 23.1 failed, so it went into 23.2 instead. It is my understanding that CEDET's smart completion engine reached a performance and reliability point that made it desirable to have in Emacs.

Emacs currently includes the parts of CEDET needed to make EDE, the project management system, Semantic and it's user tools, and SRecode all work from a user perspective. Emacs lacks the Semantic development environment, needed for writing new language support, and COGRE, the UML diagram editing tool.

Yes. It is important for users with a stock Emacs to develop new languages using the missing Semantic development tools. I don't know if COGRE will ever go in, though I expect that this will be done via the new package management system [elpa].

EML: I have used Visual Studio more than Eclipse, and certainly watched demos on how these and other tools work.

These tools win over CEDET's features in that they usually integrate directly with the compiler, VM or whatever, and have very good completion engines and UIs that you can interact with.

CEDET wins in that you don't need a compiler, or even code that can compile for it to work and start providing useful completions. It can infer an awful lot from a project.

CEDET's language support structure is thus simple in comparison, and CEDET supports many more languages as a side effect. It also wins because it is in Emacs, and I've done my best to try and match the "Emacs Way". For an Emacs user, this is intuitive, but can appear quirky to outsiders.

EML: There are a lot of language specific solutions like GCCSense, slime, JDEE, and others out there. These projects are great in that they take a language, and push it to the edge of what you can do, and the users generally love that stuff. When someone wants to do the same thing, like when CSDE started for C#, and it tried to copy JDEE, it was just that, a copy that didn't quite make it.

It is my hope that CEDET will become the target of choice for users who want to make their language support in Emacs the best. They will save a lot of time doing so as well. The same infrastructure for integrating in external tools can be used to get improved results out of CEDET, but CEDET will handle converting that into a representation that would then allow any tool built on CEDET to work. This is the same model that worked well for comint.el, and gud.el.

Yasnippet is a bit different in the way it "competes" with SRecode. My first implementation of SRecode tried recycling tempo templates, but I couldn't get it to work. In fact all the template systems I investigated fell short of what I was trying to do, so I had to roll my own, and ended up using a variant of the Google template format.

The key difference is that the goal was for SRecode to provide a series of base templates for code generation. A tool writer would then write some tool to generate code. A user would then use the tool, and say "This is great, how do I change where the { goes?"

The answer is to override the template with that detail in it without interfering with the system templates. That only works if the templates are sufficiently granular that the changed template can be simple. Template reuse needs to be high so that if your company formats your methods as:

int mymethod() { implementme() };

instead of

int mymethod() {
}

that one template change will allow this to happen for all code generated from every tool.

Thus, the audience for yasnippet and SRecode is quite different. Of course you could do yasnippet like things with SRecode if someone took the time to improve the field-editing feature in SRecode, but that has not been my focus.

EML: I watch the emacs-devel mailing list, mainly to see if anything related to CEDET goes by that I can help with, or what the latest cool feature might be. My first contribution of Speedbar to Emacs in Emacs 20 helped drive some features related to overlines, boxes, and other face attributes that appeared in Emacs 21.

In the future, once CEDET and Emacs cross merge techniques are hashed out, I would expect some key parts that need performance improvements might move into C. Another part of CEDET that I'd love to see become bound closer to Emacs is mode-local.el. It tries to simulate mode-local variables and mode-local functions. This is critical in a complex system like CEDET that needs to provide a language support author with fine grained control. There are good reasons not to make what is currently implemented "the Emacs way", but it would be nice to resolve those and enable mode authors a with a more powerful way to customize the user experience.

EML: Here is the short list:

• Improve Emacs/CEDET cross merging
• Offload tag storage to an external process - needed for scalability
• Design/define a "CEDET mode" as a way of simplifying the confusing array of distinct tools and modes that make up CEDET now.
• Finish the smart-context menu project
• Resolve the "code replacement" problem of parsing a block of code, transforming it, and re-creating that code in place reliably.

EML: Supporting new "stuff" in CEDET is one big win. Stuff can be:

• New project types under EDE to ease transition from something like Visual Studio to Emacs.
• Language support, such as parsers, or mode overrides. Finding ways to take existing cool tools, like JDE's beanshell, or slime's inferior lisp process and allowing it to do work for CEDET is another big win.
• Templates for code generation in new languages.

Tool writing would also be good. JDEE's author Paul Kinnucan converted many bits of JDEE to CEDET and co-designed many of CEDET's parts along the way, such as semanticdb, and that was a huge help. ECB's current maintainer Klaus has also had a big impact on the way concepts are abstracted to a tool that depends on CEDET.

Naturally, joining the mailing list and fixing reported bugs and improving the doc is also a huge help, but not as exciting as writing new code. :)

EML: Start with the cedet.info file which has many of the common setup configurations in it. If you run into something not explained well or at all, be sure to join the mailing list and be specific about how that doc failed. Very few questions on the mailing list refer to the doc, so the doc is rarely improved in a way that can help others.

Another good starting point is Alex Ott's article A Gentle Introduction to CEDET, which is very helpful.

Emacs 23(.1) has been released! After only just over two years since the previous version, emacs 23 has been released on July 29 2009. Time to celebrate! And a big thanks all the talented hackers that made it possible!

Emacs 23 brings many new features. Some of those have been discussed before in emacs-fu, and of course you can get the full list from the NEWS-file (C-h n). This is just a list of some of the highlights, in particular the end-user-visible ones. Let's go through them - of course I cannot mention all of them, so feel free to add your favorite one in the comments.

fonts & anti-aliasing

support for D-Bus and Zeroconf

(require 'zeroconf)
(zeroconf-init)
(dolist (srv (zeroconf-list-services "_printer._tcp"))
 (insert (format "\nprinter: %s" (nth 2 srv))))

support for 'headless' emacs-daemon

Emacs now support Xembed

Support for frame opacity

Internationalization

New defaults

New modes and packages, and updated ones