New in Emacs 25 - convenient compression/decompression in Dired

Today I'll describe my past and current workflows for compressing files and directories in Dired. In my opinion, Dired is one of the best features of Emacs - a great abstraction of cd+ls that lets you get things done much faster. The default binding for dired is C-x d (I bind it to C-;-d though, see my xmodmap post).

My previous workflow

To compress several files in Dired, first I compile a list of files to work on by marking them with m (dired-mark), navigating to ones that you want with n (dired-next-line) and p (dired-previous-line).

Once a list is ready, I press & (dired-do-async-shell-command), which allows me to run an arbitrary shell command. I enter:

tar -czf ~/tmp/path/foo.tar.gz *

into the minibuffer, press RET and I'm done. It's a standard shell command with 2 advantages:

1. I get TAB completion for the directory of the created archive.
2. * means the selected file list, so I don't enter them by hand.

My current workflow

Since I often forget the command for tar, and I really don't want to remember the commands for zip etc, I've implemented a more convenient approach:

(define-key dired-mode-map "c" 'dired-do-compress-to)

This new command dired-do-compress-to, bound to c, will prompt me for a file name of the output archive. So now it's easier to type in that file name, if you use ido-mode / ivy-mode / helm-mode. What's more, the command will be automatically determined from the archive extension and executed. Here's the corresponding customization variable:

(defvar dired-compress-files-alist
  '(("\\.tar\\.gz\\'" . "tar -c %i | gzip -c9 > %o")
    ("\\.zip\\'" . "zip %o -r --filesync %i"))
  "Control the compression shell command for `dired-do-compress-to'.

Each element is (REGEXP . CMD), where REGEXP is the name of the
archive to which you want to compress, and CMD the the
corresponding command.

Within CMD, %i denotes the input file(s), and %o denotes the
output file. %i path(s) are relative, while %o is absolute.")

This thing is pretty self-explanatory. It currently only supports *.tar.gz and *.zip, use M-x report-emacs-bug if you want to add more options.

Other improvements in compression/decompression

I improved the good-old Z (dired-do-compress) as well. Now it can compress directories to *.tar.gz, as well as decompress *.tar.gz and *.zip to directories. It's all automatic, you only have to press Z, either on an archive to decompress, or on a directory to compress.

Easy way to have a bleeding edge Emacs

If you want to get these improvements right now and are on a Debian type system (I use Ubuntu), you can use:

sudo apt-add-repository ppa:ubuntu-elisp/ppa
sudo apt-get update
sudo apt-get install emacs-snapshot

Then just use emacs-snapshot executable. It updates every few days.

Myself, I track the Emacs master from git. But emacs-snapshot is very useful for CI tests, and can also be used by people who don't want to build the executable from git.

How to get your improvements into Emacs

If you'd like to contribute code to the Emacs core yourself, it takes two steps:

1. Sign the Copyright Assignment (CA). This gives the Copyright for your changes to Emacs to the Free Software Foundation. This is useful so that the FSF can defend your rights in court, in case the GPL regarding your contribution is broken by someone.

2. M-x report-emacs-bug and attach a patch.

It seems that some people could have a moral objection to the CA. I see no reason for it whatsoever. Since Elisp libraries make calls to GPL code and are GPL themselves, you have to publish Elisp code under GPL, there's no choice there. GPL means basically that, while you're still acknowledged as the author, everyone else has about as much right to your code as you do. No one can hide or restrict access to it, but neither can you. The CA is a further step, which makes the FSF own the Copyright to your changes to Emacs. You submit these changes yourself, and the Copyright over these changes isn't really that useful: they're only changes - they do nothing on their own, outside of Emacs. Besides, with the FSF owning the Copyright, the range of things that you can do to your code stays exactly the same as if you owned the Copyright, as long as you publish under GPL.

To illustrate, the FSF CA is very polite and benign, compared to the CA that I have to give to Elsevier when I publish an article. That CA means that a multi-billion dollar corporation owns the right to my paper until the end of time, and can charge people to view it (including myself and my peers) as much as they see fit (currently, $30). Of course, I don't receive a dime of that money, but hey - I get published, and at least I can share my article for free for the first 50 days of the publish date. And if that one doesn't seem draconian enough for you, just think of the NDAs in commercial companies: out there, you can't even publish or mention anything related to your work. So please, if you're hating on the FSF, do reconsider, they're the good guys in my book.

Eventually, after a few submitted patches, you'll be granted commit access. This is a great way to implement small improvements faster. However, the larger issues that aren't simple improvements still need to be discussed with other developers, either on debbugs or on emacs-devel. For example, initially I went with the tar -czf command. But it turns out that it can't be used on Solaris 10 or AIX 7.1. Whatever those things are, people still use Emacs on them, and it's important that the core features are usable on all supported systems.