Re: Image mode

["Stuart D. Herring" <herring@lanl.gov>]

>>>> Thirdly, make the function image-type-auto-detected-p scan
>>>> auto-mode-alist for a non-image-mode match, and returns nil if one is
>>>> found.
>>>
>>> This should return nil unless auto-mode-alist suggests image mode
>
>> That is pointless. We might as well remove image-mode from
>> magic-mode-alist.
>
> I thought it was the beauty of his proposal.  Yes, let's remove it from
> magic-mode-alist.

`image-mode' isn't on `magic-mode-alist'; `image-mode-maybe' is, and
although perhaps Stefan's stance of nixing it entirely is best, it seems
to me that the -maybe function belongs there.  Visiting foo.bar with a
JPEG header in it ought to load Image Minor Mode, provide the C-c C-c
message, and leave the buffer in Fundamental Mode, just as visiting foo.c
with the same contents should load, provide, and leave in C mode.  I think
(I hope) that's what the effect of Chong Yidong's proposal with my
suggestions, and I think that that's what `image-mode-maybe' is for.  (I
also suggested that visiting foo.png with the same contents should load in
image-mode without displaying, but that part is less important.)

Davis

PS - As far as implementing this, and dealing with the nasty hacks of
interacting magic and auto lists, wouldn't it work to change FUNCTION in
magic-mode-alist (if not in auto-mode-alist as well) into (FUNCTION .
CONTINUE), where CONTINUE non-nil would cause the rest of the list to be
scanned for further applicable functions (and would allow the processing
of other variables if no later line with CONTINUE nil matched)?  It seems
that such a generalization would be useful without being too heavy-handed;
for compatibility, for a while, a symbol (as most instances of FUNCTION
are) could be treated as (list SYMBOL).

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.