Ar an dara lá de mí na Nollaig, scríobh Stephen J. Turnbull: This ChangeLog was unclear and muddled because I was trusting the implementation of the (eq t print-gensym) behaviour to not be buggy--I thought the problem was in the byte compiler. That wasn’t it, though; the behaviour of the Lisp printer when you revert this change and recompile mule/*.elc is what’s broken. The non-boilerplate code of greek.elc if you do that looks like this: (byte-code "[byte codes omitted]" [#1=#:G79030 #2=#:G79075 #3=#:G79053 #4=#:G79031 #5=#:G79029 [lots and lots of constants omitted] #1=#:G79032 upper lower greek latin-1 case-table syntax-table case-fold-search] 12) This means that somewhere in the guts of the printing of those [lots and lots of constants], one of the print functions reset print-gensym-alist where it shouldn’t have. A bit of browsing doesn’t tell me which, but it should be possible to set a watchpoint on it and work it out. The Cygwin GDB isn’t being co-operative with me in this right now, though. We (and GNU) normally don’t see this problem because for defvars, defuns, defmacros, defconst and autoloads, print-gensym was always bound to a cons, so the print-gensym-as-t behaviour wasn’t thoroughly tested. This is actually, slightly to my surprise, independent of the emacs-w3m problem. The issue with the latter is that readevalloop resets Vread_objects with each new top level form--see lread.c:1490--so it is impossible to re-use an uninterned symbol from one call to (byte-code ...) to the next. One #'custom-declare-variable call using one uninterned symbol followed by another re-using the same symbol will always break. -- ¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir precipitadamente de la aldea por culpa de la escasez de rinocerontes? _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches