I wrote:
Back in February, nbecker(a)fred.net had a problem where
tar-mode.el
and crypt.el didn't work together. Well, I'm running into the same
situation (w/XEmacs 21.1.4), and, after a little debugging, I don't see
how tar-mode can exist with any mode that handles compression.
OK, after more digging, I think I've found the problem, and it's a
bug in tar-mode. I don't understand why more people aren't encountering
this problem, though.
In a nutshell:
Basically, with compressed tarballs, tar-mode is being called
before the tarball is uncompressed. This appears to be caused
by `tar-regexp' matching compressed file names; tar-regexp
should only match uncompressed file names.
Unabridged version:
The twisty path is convoluted, but here's what should be happening
(this is for crypt.el, but the proposed fix also works for
jka-compr.el):
* find-file-noselect gets called (of course) as part of the find-file
process.
* find-file-noselect calls "normal-mode" before running the
find-file-hooks:
(unless nomodes
(normal-mode t)
(run-hooks 'find-file-hooks))
* When tar-mode.el is loaded, it overrides the definition of
"normal-mode" with it's own definition: tar-normal-mode. Basically,
when tar-normal-mode is called, if the current buffer's filename
matches a regexp ("tar-regexp") for tar filenames, the buffer is
immediately placed into "tar-mode". In other words, "normal-mode"
is
turned into "tar-mode".
***** This is where the error is occurring *****
The compressed buffer should not be placed into tar-mode at this time.
This error is occurring because tar-regexp will match the names of
compressed files; tar-regexp should only match the names of
uncompressed tar files.
* At this point, tar-normal-mode should think that the current buffer is
not a tarball, and should call the old definition of normal mode.
* The find-file-hooks are then called. Eventually, the buffer gets
uncompressed, and the uncompression code calls set-auto-mode, which
calls tar-mode and parses the just-uncompressed tarball correctly.
It's interesting to note that tar-regexp isn't required for either
crypt.el or jka-compr.el to work; for both of these compression modules,
the only important thing is that tar-regexp NOT match the compressed
file name. In the case of crypt.el, tar-mode is set via set-auto-mode
when the crypt-find-file hook is called. In the case of jka-compr.el,
tar-mode is also set via set-auto-mode, but from the call to the old
normal-mode function.
A valid setting for tar-regexp is only required if you load
uncompressed tarballs.
--
Darryl Okahata
darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.