VM-BUG: "Unrecognized property" alias-coding-systems
Aidan Kehoe
kehoea at parhasard.net
Fri May 9 04:10:13 EDT 2008
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?
More information about the XEmacs-Beta
mailing list