[PATCH] automatically handle .xz suffix (XZ-compressed files), too

[PATCH] automatically handle .xz suffix (XZ-compressed files), too

[Jim Meyering]

Any objection to my committing this?

From ad102774cf300cde688e23e174c6551b569f0b96 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Mon, 18 May 2009 11:33:03 +0200
Subject: [PATCH] automatically .xz suffix (XZ-compressed files), too

* jka-cmpr-hook.el (jka-compr-compression-info-list): Add xz.
XZ is the successor to LZMA: <http://tukaani.org/xz/>
---
 lisp/jka-cmpr-hook.el |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/lisp/jka-cmpr-hook.el b/lisp/jka-cmpr-hook.el
index 96e9513..fa2fd40 100644
--- a/lisp/jka-cmpr-hook.el
+++ b/lisp/jka-cmpr-hook.el
@@ -219,6 +219,10 @@ options through Custom does this automatically."
      "compressing"        "gzip"         ("-c" "-q")
      "uncompressing"      "gzip"         ("-c" "-q" "-d")
      t t "\037\213"]
+    ["\\.xz\\(~\\|\\.~[0-9]+~\\)?\\'"
+     "XZ compressing"     "xz"           ("-c" "-q")
+     "XZ uncompressing"   "xz"           ("-c" "-q" "-d")
+     t t "\3757zXZ\0"]
     ;; dzip is gzip with random access.  Its compression program can't
     ;; read/write stdin/out, so .dz files can only be viewed without
     ;; saving, having their contents decompressed with gzip.
--
1.6.3.1.135.g540c.dirty

Re: [PATCH] automatically handle .xz suffix (XZ-compressed files), too

[Ulrich Mueller]

>>>>> On Mon, 18 May 2009, Jim Meyering wrote:

> Any objection to my committing this?

This still hasn't made it into CVS. I think it would be short-sighted
to omit XZ support from 23.1, and the patch looks safe to me.

Ulrich

Re: [PATCH] automatically handle .xz suffix (XZ-compressed files), too

[Jim Meyering]

Ulrich Mueller wrote:
>>>>>> On Mon, 18 May 2009, Jim Meyering wrote:
>
>> Any objection to my committing this?
>
> This still hasn't made it into CVS. I think it would be short-sighted
> to omit XZ support from 23.1, and the patch looks safe to me.

Thanks for speaking up.
I too was surprised by the lack of response,
considering I posted about this three times, and even Cc'd
the two maintainers explicitly once.

Had it not been for the problems at savannah,
I would have gone ahead and committed about then.

Barring any objection, I'll commit this on the trunk in a few hours, too.

Re: [PATCH] automatically handle .xz suffix (XZ-compressed files), too

[Chong Yidong]

Jim Meyering <jim@meyering.net> writes:

>> This still hasn't made it into CVS. I think it would be short-sighted
>> to omit XZ support from 23.1, and the patch looks safe to me.
>
> Thanks for speaking up.
> I too was surprised by the lack of response,
> considering I posted about this three times, and even Cc'd
> the two maintainers explicitly once.
>
> Had it not been for the problems at savannah,
> I would have gone ahead and committed about then.
>
> Barring any objection, I'll commit this on the trunk in a few hours

Please go ahead and commit to the trunk, but it's too late for 23.1.

Re: [PATCH] automatically handle .xz suffix (XZ-compressed files), too

[Richard Stallman]

    >> This still hasn't made it into CVS. I think it would be short-sighted
    >> to omit XZ support from 23.1, and the patch looks safe to me.
    >
    > Thanks for speaking up.
    > I too was surprised by the lack of response,
    > considering I posted about this three times, and even Cc'd
    > the two maintainers explicitly once.
    >
    > Had it not been for the problems at savannah,
    > I would have gone ahead and committed about then.
    >
    > Barring any objection, I'll commit this on the trunk in a few hours

    Please go ahead and commit to the trunk, but it's too late for 23.1.

There is no need to be rigid in carrying out policies about what
changes to install.  To do a good job of maintaining Emacs doesn't
require acting like government bureaucrats.