Ar an naoiú lá de mí Bealtaine, scríobh Stephen J. Turnbull:
Aidan Kehoe writes:
> And ignoring condition-case is what debug-on-error does, and is documented
> to do, and that seems to have been your problem.
Read my message again. That's *not* a "problem".
I want to be told that it's OK that VM is asking for coding system
properties that AFAIK we don't have, especially since VM is currently
not handling MIME decoding of any kind very well for me.
VM is intentionally asking for coding system properties that we don’t have,
and expects nil in such a case. This is well and good:
(let
[...]
((ourtermcs (coding-system-name
(or (car
(coding-system-get
(console-tty-output-coding-system)
'alias-coding-systems))
(coding-system-base
(console-tty-output-coding-system))))))
The logic behind it reflects the difference between our coding system
implementation and that of GNU; we have opaque coding system objects, they
have symbols with plists. So when we alias something, say, cp1252 to
windows-1252, this code gives the canonical coding system name:
(coding-system-name (check-coding-system 'cp1251))
=> windows-1251
whereas they need to use the alias-coding-systems property, and hope it’s
been set correctly:
(car (coding-system-get (check-coding-system 'cp1251) 'alias-coding-systems))
=> cp1251
It doesn’t make sense to have #'coding-system-get subject to interruption
from a debug-on-signal setting.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta