[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eight-bit char handling in emacs-unicode

From: Kenichi Handa
Subject: Re: eight-bit char handling in emacs-unicode
Date: Sat, 22 Nov 2003 10:25:36 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

In article <jwvvfpdsrab.fsf-monnier+emacs/address@hidden>, Stefan Monnier 
<address@hidden> writes:
>>  It is perfectly possible to live in such an environment
>>  where only the charset iso-8859-1 is used but only the
>>  coding system utf-8 is used.  In this environment, the
>>  results of encode-coding-string and string-make-unibyte are
>>  of course not the same, but still both operations are
>>  meaningful.

> I see that encode-coding-string does the utf-8 encoding, but what
> does string-make-unibyte do in such a case and what is it used for ?

It gets iso-8859-1 code-points of all characters in a
multibyte string and concatenate them (the same as what is
does in latin-1 lang. env.).

In his environment, he has no problem in using unibyte
buffer because it can represent all characters he wants.

>>>  Until now, I always thought that Emacs only dealt with
>>>  - byte streams representing encoded sequences of code points: case 1.
>>>  - sequences of internal character codes (internally encoded in emacs-mule
>>>  or unicode depending on the branch you use): case 3.
>>>  Is there any place where we deal with sequences of code points of external
>>>  charsets really (other than in the degenerate case where such a sequence
>>>  is indistinguishable from case 1, maybe).

>>  I'd like to repeat that although we don't have such an
>>  environment now,

Ah, no, we have UTF-8 lang. env. now.

>> it doesn't mean it is impossible to assume such
>> environment.

> I guess I don't understand how that is possible (and useful) and what that
> would look like.

Please try C-x C-m L utf-8 RET and see how
string-make-unibyte and string-make-multibyte work.

Ken'ichi HANDA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]