Re: eight-bit char handling in emacs-unicode

[Stefan Monnier]

> It is used for not loosing information about text even if
> you kill a text in a multibyte buffer and paste it in a
> unibyte buffer.

That's the kind of concrete case I needed, thank you.
Now I'll have to go back and reread the thread to understand things
better.  Are there other cases like that ?

Also, should we really allow such a thing ?
I mean, it's a dangerous operation since it only works if the user
is lucky enough to use just the right subset of characters.  So we
should at least signal an error if the conversion is unsafe (in
that make-string-multibyte will not recover the original string).

BTW, in which kind of circumstances is the user presented with both
a multibyte buffer and a unibyte buffer ?

> Are you talking about the actual Emacs Lisp codes that
> explicitely call make-string-unibyte?  I've been talking
> about the functionality of make-string-unibyte itself,
> especially about the implicit call to the C function
> copy_text that does the same thing as make-string-unibyte.
> Is that the reason why it seems that we are talking at corss
> purposes.

I'm talking about both.

> What is the right thing to do when a multibyte Japanese text
> is being pasted into a unibyte buffer?

> I think signalling an error is the only right thing, and
> I've never objected to make copy_text and
> Fstring_make_unibyte signal an error in such a case.

I agree on the signalling, of course, I just want to push it further
and signal even when pasting latin-2 multibyte text into a unibyte buffer.
After all, why should Slovak users be able to do that but Japanese users
not ?  In my view, everytime we use this kind of thing, we're taking
a temporary shortcut that is "good enough for 8bit users" but not for the
rest of the world.
AFAIK, unibyte buffers should only be used internally and never presented
to the user.  This is because unibyte buffers contain bytes (in my view)
whereas the user wants to see characters.


        Stefan