>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

	Please consider the revised patch MIMEd.

	* tar-mode.el: Allow for adding new archive members.
	(tar-new-regular-file-header, tar--pad-to, tar--put-at)
	(tar-header-serialize): New functions.
	(tar-current-position): Split from tar-current-descriptor.
	(tar-current-descriptor): Use it.
	(tar-new-entry): New command.
	(tar-mode-map): Bind it.

[…]

 >> BTW, I wonder if it makes sense to split the make-tar-header form
 >> (with all the nil’s there) off tar-new-entry into a new
 >> (tar-new-regular-file-header filename &optional size time) function?

	(Done.)

 >> I guess that’d ease the creation of Tar archives from Emacs Lisp
 >> code; (and I already imagine some uses to that.)

 > BTW, if you're interested in hacking on tar-mode, I keep dreaming of
 > plugging it into file-name-handler-alist so you can just visit
 > /foo/bar.tar.gz/somefile, use dired on it, ...

	I’m not all that familiar with file-name-handler-alist, but I
	guess I could check it out.  (Although at this point I’m simply
	interested in creating Tar archives from the contents of Emacs
	buffers, – without having them saved into files, that is.)

	Curiously, what would be the sensible behavior for Emacs when
	the copy of the Tar archive kept in the *tar-data* buffer
	happens to differ to the on-disk state of the respective file?

-- 
FSF associate member #7257  np. Вселенская большая любовь — Гражданская Оборона