Katsumi Yamaoka <yamaoka(a)jpl.org> writes:
>>>>> In
<1696-Thu31Oct2002194428-0100-oub(a)nfsrrv.mat.ucm.es>
>>>>> Uwe Brauer <oub(a)ucmail.ucm.es> wrote:
> I am not sure whether this is really a xemacs bug, or is caused from
> some of my packages. However it frequently occurs, and it refers to
> decode-coding-region a function I thought only appears in the mule
> version of xemacs.
Though it is unrelated to the subject, decode-coding-region is
available even in non-Mule XEmacs 21.4 if it is built with the
configure option --with-file-coding.
Thanks for your answer
Aha what is the benefit of this option. I chose to have a mule free
Xemacs because it is faster and mule xemacs has corrupted sometimes my
files. I can solve my Problem by recompiling xemacs with this option,
I am willing to do so, as long as I know what I am doing.
> Signaling: (void-function decode-coding-region)
> decode-coding-region(1 763 undecided) x-symbol-mode-internal(tex)
> nuke-x-symbol() kill-all-local-variables()
> VirTeX-common-initialization() LaTeX-common-initialization()
[...]
> "/home/oub/xemacs/site-lisp/packages/auctex-11.11/latex.elc"
My guess is that nuke-x-symbol, x-symbol-mode-internal and
decode-coding-region are called from the function
VirTeX-common-initialization. However, I couldn't find those things
in the most recent auctex XEmacs package. I couldn't reproduce that
error using my non-`decode-coding-region' verison of XEmacs 21.4,
either.
Could it be that the culprit is x-symbol?
Uwe Brauer