Re: Dynamic loading progress

[David Kastrup]

Philipp Stephani <address@hidden> writes:

> Eli Zaretskii <address@hidden> schrieb am Sa., 21. Nov. 2015 um 10:30 Uhr:
>
>> This is what my comments were about.  I think that you, by contrast,
>> are talking about the encoding of the _input_ strings, in this case
>> the 'documentation' argument to module_make_function and 'str'
>> argument to module_make_string.  My assumption was that these
>> arguments will always have to be in UTF-8 encoding; if that
>> assumption is true, then no decoding via code_convert_string_norecord
>> is necessary, since make_multibyte_string will DTRT.  We can (and
>> probably should) document the fact that all non-ASCII strings must be
>> UTF-8 encoded as a requirement of the emacs-module interface.
>>
>
> Or rather, an extension to UTF-8 capable of encoding surrogate code
> points and numbers that are not code points, as described in
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html
> .

That's mostly irrelevant for fixed strings as valid UTF-8 is encoded as
itself and invalid UTF-8 is encoded as well-processable invalid UTF-8.
Apart from strings generated with `string-as-multibyte' (what kind of
terrible idea is that?) or unibyte strings, all Emacs strings are
well-processable (meaning that they are represented by start byte and
extension bytes, with the start byte encoding the byte count 1-6 in the
UTF-8 typical manner even if UTF-8 itself does not go beyond the Unicode
range encodable in 4 bytes).

> Yes, provided the internal Emacs encoding is stable.

It has changed several times in the past.  It's a reasonably good bet
that the basics of its current UTF-8 scheme will stick around.

-- 
David Kastrup