Re: Coding bug in insert-file-contents-internal
"Ben Wing" <ben(a)666.com> writes:
> This is a completely tentative patch, bceause I'm still not
> quite clear on the interactions of bindings, GCPRO,
> unwind-protect and the like in the C layer. I *think* it's
> pointless to specbind() DEFVAR_LISPed variables, because it
> seems to me that this would break the magic link between the
> C variable and the Lisp symbol --- the magic forwarding
> symbol would wind up on the specbinding stack --- and the C
> code uses the variable... so I've tried to
> record_unwind_protect it instead. I'm not quite sure if I've
> done it right, or if I need to GCPRO something (I don't think
> so: stuff on the specbinding stack and stuff in DEFVAR_LISPed
> variables are both found by the garbage collector anyway,
> right?) record_unwind_protect()?)
>
>
> It compiles, I don't know if it runs, I don't know if it's
> safe
Yes.
> I don't know if there's a better way to do it:
Yes.
record_unwind_protect() and specbind() (of a Q... Symbol that names the
variable) are both fine. Easiest/best is internal_bind_lisp_object().
Whatever. I think it is rather likely that the fix is not in the yet
released 21.4.17, and even if it were, I don't want to deprecate
21.4.15 for preview-latex use if I can avoid it.
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?
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.
Correct?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum