Re: Inadequate documentation of silly characters on screen.

[Stefan Monnier <monnier@iro.umontreal.ca>]

> So the problem is that because characters are integers and vice versa,
> there's no way for the user to let Emacs duck-type multibyte vs
> unibyte strings for him.  If he cares, he needs to check.  If he
> doesn't care, eventually Emacs will punish him for his lapse.

> I suppose subst-char-in-string is similarly useless for Alan's
> purpose, then?  What he really needs to use is something like

>     (replace-in-string str "\n" "ñ")

> right?

Pretty much yes.  When chars come within strings, the multibyteness of
the string indicates what the string elements are (chars or bytes), so
as long as you only manipulate strings, Emacs is able to DTRT.
As soon as you manipulate actual chars, the ambiguity between chars and
bytes for values [128..255] can bite you unless you're careful about how
you use them (e.g. about the multibyteness of the strings with which
you combine them).

That's where `aset' bites.  I hate `aset' on strings because it has
side-effects (obviously) and because strings aren't vectors so you can't
guarantee the expected efficiency, but neither are the source of the
problem here.  So indeed subst-char-in-string suffers similarly.


        Stefan