Re: [Q] Re: Version of image-mode.el which doesn't use format-alist
Ville Skyttä wrote:
> > The new mode breaks XEmacs 21.1.14. This is because there
are
> > references to (at least these) functions you've removed in the new mode
> > in lisp/format.el: image-decode-jpeg, image-decode-gif,
> > image-decode-png, image-decode-xpm, image-decode-tiff,
> > image-decode-tiff. As Stephen already noted, these have been removed in
> > newer XEmacsen. Some `define-obsolete-function-alias'es or wrappers to
> > `image-decode' would be needed, since packages need to work with XEmacs
> > 21.1 and newer at the moment.
>
> I can put those functions back in, although I have no idea whether it
> will work correctly (presumably image-decode would end up being called
> twice; once via format-alist, and once from image-mode).
>
> A better fix might be for image-mode-install to just remove the
> entries from format-alist; IIRC, the consensus was that they shouldn't
> have been there in the first place.
Yep, that's how I've understood the consensus too. But removing stuff
from format-alist sounds a bit scary to me; that might cause problems
eg. if we later for some reason decide to put the entries back there.
How about if the old defuns were put back into image-mode, but as dummy
`make-obsolete'd ones that don't do anything? Would that work?
No. So long as the format-alist entries remain, the associated
functions must change the data such that the beginning of the data no
longer matches the specified regexp. Otherwise, the functions will
just be called again, resulting in an infinite loop. Consequently, a
no-op won't work.
The original image-decode function solved this problem by deleting the
data; if image-toggle-decoding was called, it would re-insert the data
with:
(insert-file-contents-literally buffer-file-name)
This won't work if the data didn't come from a file, and won't work as
expected if the file has since changed.
The new version retains the data, but encloses it in an extent with
the 'invisible' property, and with the decoded image as the extent's
end glyph; undoing the decoding with image-toggle-decode simply
removes the extent.
AFAICT, providing the new image-mode.el under a different name won't
work either. So long as the format-alist entries exist, they will tend
to interfere with any attempt to read image files. The biggest problem
is that there is an entry for XPM files, which one might reasonably
want to treat as text files.
--
Glynn Clements <glynn.clements(a)virgin.net>