RE: Image mode

[Drew Adams]

Everyone's having such fun ;-). Just to stir the waters a little more...

1. We might want to consider a binary option that if non-nil would ask you
if you want to rename an image-file's suffix when Emacs determines the file
to be of a certain image type but the current suffix is non-standard for
that type. This is the behavior of some image-display applications, such as
IrfanView.

IOW, if an option `ask-to-rename-image-file-suffix-flag' is non-nil (the
default value, IMO), and if you open a file named foo.gif and it is really a
JPEG file (not that uncommon), Emacs asks you if you want to rename it to
foo.jpg (or perhaps to .jpeg).


2. A variant (better, IMO): Instead of a binary flag, use an alist
`ask-to-rename-image-file-suffixes' to define the acceptable suffixes for
each file type and indicate whether you want to be asked about renaming. The
alist entries would be (TYPE . SUFFIXES), where:

- TYPE would be a conventional symbol naming the file type - e.g. `jpeg' for
JPEG files.

- SUFFIXES would be a list of acceptable suffixes (strings) for files of
type TYPE. nil mean that all suffixes are acceptable for TYPE (so you are
not asked about files of type TYPE).

When SUFFIXES is non-nil, whenever you attempt to open (e.g. display) a file
that 1) Emacs determines is of type TYPE and 2) has a suffix that is not in
SUFFIXES, you are asked if you want to rename the suffix to (car SUFFIXES).

The question could be posed in such a way that you could reply `y' to rename
the suffix, `n' to leave the suffix alone this time, or `!' to leave the
suffix alone and inhibit future such questions for files of that type (the
updated option value would be saved). Or `a' to get the effect of `!' for
all image-file types.

Users who don't want to be bothered by such questions can customize the
option, answer `!' for individual file types, or answer `a' to never see a
question again.

`a' would set the value to nil, which would mean to never ask a question
about any image-file types. IOW, nil is the same as an alist whose entries
all have empty values (keys only).

The default value of the option would be an alist of all supported
image-file types and the conventional (usual) suffixes. It could be
platform-dependent, but probably wouldn't need to be.


3. Variant of the variant: Let the alist, `image-file-suffixes', do
double-duty. If there is an entry for a given file type, then Emacs should
try to determine the file type without regard to the current suffix. No
entry means do not check - rely on the suffix. So, the alist ((jpeg) (gif
"gif" "GIF")) would check both JPEG and GIF files, but would ask you about
renaming an incorrect suffix only for a GIF file (no rename question for
JPEG files). It would not check PNG files at all (that is, Emacs would trust
a "png" suffix, without checking the file contents).

Note that the suffixes could also be used to deal with case-sensitivity. An
entry of (gif "gif") would prompt you to rename a file named foo.GIF, but an
entry of (gif "gif" "GIF") would not. Even on a case-insensitive operating
system, you might want to ensure that all of your image files had, say,
lower-case suffixes (e.g. for use on a different platform). This wouldn't be
the way to go about renaming zillions of files, but it might be handy to
catch the occasional straggler.


4. Variant of the variant's variant: Reverse things, using t instead of nil
to indicate that all suffixes are permitted, and using the absense of an
entry of a particular type to mean that Emacs should never open files of
that type. IOW, above, with ((jpeg) (gif "gif" "GIF")), Emacs would always
open a file foo.png without checking its content, but in this variant, Emacs
would never open it - it would open only JPEG files (checking their content
but not asking about renaming) and GIF files (checking content and asking).
A value of ((jpeg) (gif "gif" "GIF") (png t)) would mean to a) do as before
for JPEG and GIF, b) rely upon the suffix for a PNG file, and refuse to open
a TIFF file.


5. Variant of whichever variant: Associate "Open", "Edit" etc. action
functions with image files of given types, by allowing alist entries to have
values that include pairs such as `edit my-editor'. E.g. ((jpeg (edit
my-image-editor) (open my-image-opener)) (gif "gif" "GIF" (edit
my-gif-editor)) (png (open my-image-opener) t)). If a file type doesn't have
an `open' action then use the default opener, etc., but if it has a null
`open' etc. action, then refuse to open etc. it - e.g. (png (open) t). The
action functions would be Emacs functions, but they might call upon external
programs (as async processes).


... Are we having fun yet?  Is the release having fun yet?