tar-mode and crypt revisted

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. I must be missing something, as few people seem to have problems with tar-mode. Here's what I'm seeing when compressed tar files are read: * 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. Basically, when normal-mode is called, if the current buffer's filename matches a regexp for "tar filenames", the buffer is immediately placed into "tar-mode". In other words, "normal-mode" is turned into "tar-mode". * "tar-mode" treats the current buffer as containing a tar file, and tries to parse the current buffer. * Unfortunately, the current buffer contains compressed information, and tar-mode tries to parse the compressed file as a tar file. * An error is generated because tar-mode parses garbage (i.e., you get the "#$%^&* has size -59888002 - corrupted" message). * The find-file-hooks, which handle auto-uncompression, are never called. What am I missing, or is this a bug? -- 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.