bug#10506: 24.0.92; Visiting the Guile v2.0.3 tarball shows binary garbage

[Glenn Morris <rgm@gnu.org>]

Eli Zaretskii wrote:

>> It happens to contain a shell-script (depcomp) near the end of the
>> tarfile, and that shell-script happens to have a footer that starts
>> fewer than 3000 characters from the end of the tarfile, and happens to
>> contain:
>> 
>>     # Local Variables:
>>     # mode: shell-script
[...]
> But this is a regression from Emacs 23.3, which doesn't have this
> problem.

The change is because set-auto-mode now checks for "mode:" at the end of
the file earlier than it did in 23.3 (specifically, before
auto-mode-alist). This is for correct handling of some dir-local
variables (bug#8586), but also seems like the right thing to do in
general. It is however wrong in this specific instance, and in other
instances of binary files.

It works in 23.3 because auto-mode-alist is consulted first, chooses
tar-mode, and this then binds local-enable-local-variables to nil.

I was going to say that I think it would still go wrong in 23.3 if you
could somehow construct a tar file with a -*- mode -*- entry on the
first line, but then I discovered inhibit-first-line-modes-regexps.

I think the right solution is to extend the meaning of
inhibit-first-line-modes-regexps, so that we ignore mode: entries
(indeed, all file local variables) in matching files wherever they
appear (not just the first line). IMO, this is obviously the sense in
which one would want to use such a variable - I can't think of a case
where one would want to ignore mode in the first line, but respect it at
the end, or ignore all mode: settings but still respect other file local
variables.

This variable is not documented in the manual, so I would not feel too
bad about extending it in this way; it's just a shame that it has the
name it does.


A final comment: it seems to me that anything in auto-coding-alist with
a no-conversion* coding should be in inhibit-first-line-modes-regexps as
well, since the meaning in both cases is basically "this is a binary
file". Are there any exceptions?


Thoughts?