[Top][All Lists]

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

Re: Crashes with non-default language environments

From: Juri Linkov
Subject: Re: Crashes with non-default language environments
Date: Mon, 11 Feb 2008 23:27:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

>>>>> Of course, string-AS-unibyte is the worst of all three.  But nobody
>>>>> suggested to use that one.  I just suggested to replace
>>>>> string-MAKE-uniybte by string-TO-unibyte.
>>>> Where's this string-to-unibyte function?  My emacs doesn't have it...
>>> Oh, that's right, we still don't have it.  We only have the 3 variants
>>> on the uni->multi, but not on the multi->uni.
>>> I guess now is a good time to introduce it.

Ah, sorry, since I've found no such function I assumed a typo.

I think adding a new function string-to-unibyte to complement
string-to-multibyte and other 2 multi->uni functions would be a good
thing for the short term even though all these names are confusing.

>> What's really wanted here, is something like
>> vector-to-raw-string-dont-you-dare-do-any-encoding, right?
>> [As the bytecode engine wants raw bytes with the same numbers, which
>> just happened to be inside a string]
> The problem is that "no encoding" means different things to
> different people.  At some point I proposed to just throw out all those
> functions, and force people to use encode/decode-coding-string instead,
> which forces them to think a bit about what they're doing.

Since all those uni->multi/multi->uni functions have non-descriptive
names, using encode/decode-coding-string with explicit coding will
help writing more clean and less error-prone code.  So I'd give a vote
for it.

Juri Linkov

reply via email to

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