10:32 a.m.
[Moved from xemacs-patches to xemacs-beta; that's the correct
protocol, right?]
Ville Skyttä wrote:
When using this image-mode.el, starting up XEmacs spits out messages
to
the console like these:
Loading image-mode...
Loading image-mode...done
I wonder if this could be avoided somehow?
I don't know; I have no idea why it would do this if other modes don't.
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.
Finally, a small nit:
> ;;;###autoload
> (defun image-mode-install ()
> (dolist (format image-formats-alist)
> (let* ((re (car format))
> (type (cdr format))
> (regexp (concat "\\.\\(" re "\\|" (upcase re)
"\\)\\'"))
> (item (cons regexp 'image-mode)))
> (and (featurep type)
> (not (member item auto-mode-alist))
> (push item auto-mode-alist)))))
I guess the last chunk could use `add-to-list', something like:
(and (featurep type) (add-to-list 'auto-mode-alist item))
OK; I'll change that.
--
Glynn Clements <glynn.clements(a)virgin.net>
11:59 a.m.
New subject: [Q] Re: Version of image-mode.el which doesn't use format-alist
On Sun, 2002-10-20 at 12:32, Glynn Clements wrote:
[Moved from xemacs-patches to xemacs-beta; that's the correct
protocol, right?]
Right, thanks :)
> When using this image-mode.el, starting up XEmacs spits out
messages to
> the console like these:
> Loading image-mode...
> Loading image-mode...done
> I wonder if this could be avoided somehow?
I don't know; I have no idea why it would do this if other modes don't.
Anybody?
> 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?
--
\/ille Skyttä
scop at xemacs.org
1:23 p.m.
New subject: [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>
5:37 p.m.
New subject: [Q] Re: Version of image-mode.el which doesn't use format-alist
On Sun, 2002-10-20 at 15:23, Glynn Clements wrote:
> 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.
Ok, thanks for the explanation. Removal of the format-alist entries
might be the best way to go then. I'm fine with it unless somebody else
points out that it will break something.
--
\/ille Skyttä
scop at xemacs.org
10:31 a.m.
New subject: [Q] Re: Version of image-mode.el which doesn't use format-alist
>>>> "Ville" == Ville Skytt <Ville>
writes:
> > When using this image-mode.el, starting up XEmacs spits out
> messages to > the console like these: > Loading image-mode...
> > Loading image-mode...done > I wonder if this could be avoided
> somehow?
> I don't know; I have no idea why it would do this if other
> modes don't.
Ville> Anybody?
Other modes _do_ do this if they're called early enough. I forget how
that happens offhand. Does it happen with -vanilla?
> 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.
I think this is best.
Ville> Yep, that's how I've understood the consensus too. But
Ville> removing stuff from format-alist sounds a bit scary to me;
Ville> that might cause problems eg. if we later for some reason
Ville> decide to put the entries back there.
This stuff was just plain broken; having image-mode-install take them
out isn't going to break things worse. As long as users get what they
expect, they aren't going to put those back into format-alist, and we
definitely will not do so.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
6:15 p.m.
New subject: [Q] Re: Version of image-mode.el which doesn't use format-alist
On Mon, 2002-10-21 at 12:31, Stephen J. Turnbull wrote:
>> > When using this image-mode.el, starting up XEmacs
spits out
>> messages to > the console like these: > Loading image-mode...
>> > Loading image-mode...done > I wonder if this could be avoided
>> somehow?
>> I don't know; I have no idea why it would do this if other
>> modes don't.
Ville> Anybody?
Other modes _do_ do this if they're called early enough. I forget how
that happens offhand. Does it happen with -vanilla?
No it doesn't, if you mean something like
xemacs -vanilla -l ./image-mode.el
Ville> Yep, that's how I've understood the consensus
too. But
Ville> removing stuff from format-alist sounds a bit scary to me;
Ville> that might cause problems eg. if we later for some reason
Ville> decide to put the entries back there.
This stuff was just plain broken; having image-mode-install take them
out isn't going to break things worse. As long as users get what they
expect, they aren't going to put those back into format-alist, and we
definitely will not do so.
Ok, so be it. Glynn, could you make this change to your image-mode.el
and send the revised one? The format-alist of 21.1.14 is at
<http://cvs.xemacs.org/viewcvs.cgi/XEmacs/xemacs/lisp/format.el?rev=1.9&am...;.
--
\/ille Skyttä
scop at xemacs.org
3:05 a.m.
New subject: [Q] Re: Version of image-mode.el which doesn't use format-alist
>>>> "Ville" == Ville Skytt <Ville>
writes:
> Other modes _do_ do this if they're called early enough. I
> forget how that happens offhand. Does it happen with -vanilla?
Ville> No it doesn't, if you mean something like
Ville> xemacs -vanilla -l ./image-mode.el
That means that something in your init code (including custom.el) is
invoking image-mode (possibly implicitly via an autoload). I'm not
sure why this ends up on the console, though; by the time we get to
init.el we should have everything initialized, including the diversion
of message from stdout to *Warnings* and/or " *Message-Log*".
I'll look into it.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8:29 p.m.
New subject: [Q] Re: Version of image-mode.el which doesn't use format-alist
On Tue, 2002-10-22 at 05:05, Stephen J. Turnbull wrote:
>> Other modes _do_ do this if they're called early
enough. I
>> forget how that happens offhand. Does it happen with -vanilla?
Ville> No it doesn't, if you mean something like
Ville> xemacs -vanilla -l ./image-mode.el
That means that something in your init code (including custom.el) is
invoking image-mode (possibly implicitly via an autoload).
Hmm, weird. I moved away my ~/.emacs and ~/.xemacs/(init|custom).el,
and started "xemacs -no-site-file -no-init-file" with only the new
text-modes package (with the new image-mode) built into
~/.xemacs/xemacs-packages/, and I still get the messages on console.
I'll look into it.
Thanks a bunch, let me know if I can help.
--
\/ille Skyttä
scop at xemacs.org
8067
days inactive
8069
days old
7 comments
3 participants
participants (3)
-
Glynn Clements -
Stephen J. Turnbull -
Ville Skyttä