Re: Coding bug in insert-file-contents-internal
Nix <nix(a)esperi.org.uk> writes:
[sorry for response delay. back now.]
You just watch your wrists, nobody's upset.
On Mon, 07 Feb 2005, David Kastrup whispered secretively:
> I take it that this bug has not been encountered except by people
> using special software, and this even though XEmacs comes with tool
> bars and things. Am I right to conclude that the xbm and xpm image
> loading modes of XEmacs (which are the default formats used for
> icons unless I am mistaken) basically are not affected by this bug
> since they are principally ASCII formats and seemingly coded in a
> manner that don't mind if the end of line conversion is set to some
> weird value via the dired.el operation?
That's true. This only breaks loading of PNGs and things like that
from files.
> If this could be asserted, it would make loading preview-latex
> somewhat faster under XEmacs and would remove the necessity for at
> least some workaround code. We would still need workaround code
> for the actual in-text images generated by TeX (which are usually
> PNG), but for nothing else.
Well, I was talking nonsense here. The load time of preview-latex is
not really affected, at least now, because we still search for the
icon images anyway. Strictly speaking, this does not make sense since
the package installation process should be aware of where it placed
the images instead of groping all over the disk for them. But that's
a preview-latex internal problem and does not concern XEmacs.
The previous problem where the icons needed to be present at
compilation time is gone. I changed the respective code in
preview-latex.
The `workaround code' is simply to read it ourselves and then
use
:data instead of :file, I think.
This is the stuff that is actually costing performance since a
preview-latex run can easily include hundreds to thousands of images,
most of which will probably not ever need loading before they get
replaced by the next batch, because the part of the file where they
are located might not be actually displayed.
This is possibly more efficient because we can cache it ourselves,
as well (although this may be overdesign) :)
This is an overdesigned excuse... Anyway, once this gets fixed and
the fix is operative, I'd be glad to hear a related _condition_ with
which we can reliably test for the presence of the fix
(emacs-version<= does not cut it since both Emacs 21.4 and 21.5 series
are involved), so that we can then stop preloading potentially
unneeded image files in preview-latex and leave that job to XEmacs,
once XEmacs is capable of dealing with it.
Thanks,
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum