"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
I _was_ going to go fix the doc, but discovered more discrepancies.
Lispref says
(concat "abc" (list 120 (+ 256 121)) [122])
@result{} "abcxyz"
It's a documentation bug. I don't see why
(concat "abc" '(120 377) [122])
would possibly return "abcxyz". when the number 377 does not
correspond to the ASCII character ?y.
This is still considered a feature, right?
Right. Since `concat' produces a string, all the list and vector
elements are coerced to characters. The only coercion that makes
sense for numbers is `int-char', and that should be documented.
And yes, I'm aware that int-char is not the nicest function in the
world, but within the bounds of XEmacs it makes sense and actually
creates the least broken behaviour. For instance, this works both
with and without Mule.
(apply #'concat (mapcar #'list "Hrvoje Nikšić"))
--with-mule=no XEmacs does as the manual says (computes the
character modulo 256), right?
It could signal an error just as well. That's what I think it
*should* do, anyway. Calling int-char is one thing; accepting numbers
outside the available range and truncating them silently is another.