Blog - /Tech

Emacs Muse 3.20 is now available.

Emacs Muse is an authoring and publishing environment for Emacs. It simplifies the process of writing documents and publishing them to various output formats. One of the principal aims in the development of Muse is to make it very easy to produce good-looking, standards-compliant documents.

This will be my last release as maintainer of Emacs Muse, and the project will need a need maintainer effective immediately.

Release info

Tarball

http://download.gna.org/muse-el/muse-3.20.tar.gz

Zip file

http://download.gna.org/muse-el/muse-3.20.zip

I had a guest over who ssh'd into a machine named similarly to one of my top-level directories. This caused M-x find-file to show his machine every time I tried to tab-complete on that directory. Very annoying. It turns out that tramp is to blame: it reads ~/.ssh/known-hosts every time find-file is run. To make that bad completion go away, just remove all mentions of the machine name from ~/.ssh/known_hosts.

I don't think it has been announced elsewhere yet, so I thought I'd mention this: I've stepped down from my responsibilities as an HCoop Sysadmin. The primary reason is lack of motivation to work on remote system administration, particularly without machines to stage changes on before they hit prime time. Programming as a day job has been very good to me, to the extent that sysadmin work feels like drudgery.

It's been instructive. I had to adapt a lot of essential utilities like Mailman, Exim, and Courier to work with the AFS filesystem. Hacking Exim was easily the most invasive AFS-related change, and involved me grepping through the large Exim spec document numerous times. I also had to work on a cron script hack to deal with the mess procmail makes when it can't write to AFS for whatever reason.

It has also been fun. I've worked on a method for using git to work on custom changes to Debian packages. I've been impressed with the idea of directory-level ACL's, as implemented by AFS. I've been less than impressed with the idea of tokens that expire, causing standard tools to display weird error messages. I've written and organized a major collaborative documentation effort: the HCoop Member Manual. I've automated much of the work of signing and managing SSL certificates as a site-specific certificate authority.

I had an idea for a new Emacs mode yesterday while talking with a coworker: a clipboard manager for Emacs. Think M-x browse-kill-ring, but able to pick up on yanks and kills made by other X programs, and set the current X (and Emacs) selection. An initial search didn't yield anything similar to this, so it might be interesting to implement — don't think I'll do it myself, though, since XFCE's Clipman is good enough for me.

Gmane is a handy way to follow mailing lists, especially those with a large volume of messages. There are cases when it is not a good idea to use it, however.

Maintainers of a project should definitely not use it to follow mailing lists for their projects. The same goes for active contributors. The reasons are as follows.

1. If your main computer breaks down and you have to rely on just websites, you would have to visit the Gmane web interface for each mailing list that you're a part of. This would mean you can't easily keep track of which messages have been seen, and becomes a hassle if you're involved in several projects.
2. More things can go wrong. Most people use something like leafnode to download messages from Gmane. I recently ran into a bug where leafnode was not fetching messages for any newsgroups (after about three weeks of being without internet access) until each newsgroup was visited and had all of its messages read. I just don't have time to investigate such things.
3. If your mailing list has a policy of sending replies both to individual senders and the list itself, this is nontrivial to do.

I'm going to stop using PGP signatures in email messages that I send. While it can be satisfying to sign off on every email by entering a PGP passphrase, it is just not worth the effort anymore. Not enough other people use them, and many of those who don't use them get confused when they receive these messages, due to their email clients sucking.

I think that the next big thing in GUI apps should be the ability to take the exact contents of a window and send them to a remote machine. The use case for this is: you start an app at home, go to work, ssh (with X forwarding) into your home machine, and realize that you need to use that app again. Normally you'd kill the app and restart it. But what if you could just "clone" the window so that it appeared on your work machine, responsive to new input? I'd love to see functionality like this being added at the toolkit level (i.e. GTK, Qt) so that application developers would not have to do any work to activate it.

One of the nice things about running many apps in Emacs is that I already have that ability. I can just use the multi-tty support in Emacs 23 to open up either a terminal window or a new GTK frame, and then switch to the buffer that contains the app.