emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cpio-mode


From: Michael Albinus
Subject: Re: cpio-mode
Date: Fri, 02 Feb 2018 17:30:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Douglas Lewan <address@hidden> writes:

> Michael,

Hi Doug,

> First: Oh, my! I've been reading about a missing cpio mode in the
> emacs TODO file for years, I'd sort of assumed that there was little
> work on it. (I do admit that when I'd last joined this list, I did
> receive a few attempts to start such a project.)

I haven't updated the TODO file yet, so you wouldn't still know it ...

> Your work sounds similar to mine. Indeed, my goal is to write
> something like a dired front end to all the cpio formats, with
> relatively easy extensibility to others.

That fits perfectly. I have written a *back end*, based on the file name
handler approach of Emacs. See (info "(elisp) Magic File Names")

In fact, most of the basic operations mentioned there got a new
implementation in file .../lisp/net/tramp-archive.el. You don't need to
configure anything in your Emacs, those alternative implementations come
into play based on the file name. Just open the virtual file
"/path/to/file.cpio/", and you have a dired buffer with the contents of
the archive. Call (copy-file "/path/to/file.cpio/foo" "/tmp") etc pp.

I have written something about in the Tramp manual, check
(info "(tramp) Archive file names")

There are also test cases which could give you an impression what's
possible, see .../test/lisp/net/tramp-archive-tests.el.

This implementation has some limitations, though. It is based on GVFS,
the Gnome Virtual File System. In practice, it works only for GNU/Linux
systems. Another drawback is, that the Gnome folks haven't implemented
write access for archives, although it would be possible. Here I'm still
a little bit undecided how to continue.

> This should include editing,
> adding and deleting archive members. That's turned out to be a little
> more than I was expecting. Once I started looking more closely, dired
> is much larger that I was expecting.
>
> FYI The design is coarsely given in this diagram.
>
> ;; +----------------------+   +-------------+   +-------------+
> ;; | Format specific code |   |             |   |             |
> ;; | +---------------+    |   |             |   |             |
> ;; | | cpio-bin      |    |   |             |   |             |
> ;; | | +--------------+   |   |    CPIO     |   | dired-like  |
> ;; | +-|cpio-crc      |   |<->|    Logic    |<->|     UI      |
> ;; |   | +-------------+  |   |             |   |             |
> ;; |   +-| hpbin       |  |   |             |   |             |
> ;; |     | +------------+ |   |             |   |             |
> ;; |     +-| ···        | |   |             |   |             |
> ;; |       +------------+ |   |             |   |             |
> ;; +----------------------+   +-------------+   +-------------+
> ;;             Λ                     Λ                 Λ
> ;;             |                     |                 |
> ;;             V                     V                 V
> ;; +----------------------------------------------------------+
> ;; | generic code                                             |
> ;; |          +------------+ +--------------+ +-----+         |
> ;; |          | cpio-modes | | cpio-generic | | ··· |         |
> ;; |          +------------+ +--------------+ +-----+         |
> ;; +----------------------------------------------------------+
>
> Could you point me to your code? Thanks.

At a first glance, what you call "generic code" could be based on the
back end. Maybe there's something missing, but it could be a starter.

Best regards, Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]