[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.