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