Re: [BUG] with non-ascii characters in dir names
Didier Verna <verna(a)inf.enst.fr> writes:
Note that the same
change as needed to fix your bug needs to apply to the the NT
version was well. Note that top that file claims the function has been
MULE-ized.
You're right, this corrects the bug. This brings me a question
that
might be stupid, but isn't it likely that most use of XSTRING_DATA
through the code will be bogus in the same fashion[1]?
Probably. MULE is totally broken this regard. I looked at a few of
them and most of them indeed look bogus.
bolzano:vroonhof/cvs/xemacs-20/src> grep XSTRING_DATA *.c | wc -l
424
:-(
I am wondering. Suppose we were to redefine XSTRING_DATA such that it
always used 'raw-text' or maybe even 'binary' as the coding
system would that help?
about the coding system ? I mean take the same function,
unix_create_process,
where the environement is massively copied for the child to be forked. What
should we do about it ?
You mean the arguments etc.. Do we really want
'process-argument-coding-system' (this can also be a lisp list op
coding systems such that the n-th item is used as a coding sytem for
the n-th argument) en 'environment-variable-coding-system',
domain-or-host-name-coding-system.
:-(
Jan