[Top][All Lists]

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

[elpa] externals/cpio-mode 7626f39 01/61: Create README.md

From: Stefan Monnier
Subject: [elpa] externals/cpio-mode 7626f39 01/61: Create README.md
Date: Fri, 11 Jan 2019 15:25:19 -0500 (EST)

branch: externals/cpio-mode
commit 7626f39914bfecd47605a69124130b3ad01c7c0a
Author: dlewan <address@hidden>
Commit: GitHub <address@hidden>

    Create README.md
    Initial content from local CVS.
 README.md | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..30b6919
--- /dev/null
+++ b/README.md
@@ -0,0 +1,40 @@
+# -*- encoding: utf-8 -*-
+#      $Id: README,v 2018/03/08 06:10:11 doug Exp $    
+The intents of cpio-mode are the following:
+• It should be as much like dired as possible.¹
+  (The current keymap effectively duplicated dired's.)
+• It should be easy to add new archive formats to it.
+  That is, in particular, it should admit, for any inode-like archive format,
+  an absract interface that leaves the the UI intact
+  and independent of the underlying format.
+  This should, for example, allow 
+  for converting between and among archive formats nearly trivially.
+It should also allow for dired-like functions.
+Specifically, those things that dired within emacs allows.
+That includes things like
+• Adding/deleting entries
+• Editing entries
+• Changing an entry's attributes (chown, chgrp, chmod, etc.).
+To add a new archive type a devloper should be able to do so
+merely by being able to parse an entry and
+write a parsed entry back to a file.
+Right now (2017 Dec 10), the cpio-mode package supports the above
+for the "newc" format of cpio archives.
+However, the internal structure of cpio-mode implements
+all of the manipulation code in terms of parsed headers
+(which look much like inodes), so adding new formats should be
+relatively easy.
+See the documentation in cpio.el
+for a slightly more detailed description of this structure.
+There's also a package of Affiliated Buffers included
+that should be independent.
+(And one day it will be published that way.)
+¹Yes, this is a terrible requirement.
+ However, it does allow for incremental development relatively easily.

reply via email to

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