Re: Dynamic loading progress

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: Philipp Stephani <address@hidden>
>
>>     > No matter what we expect or tolerate, we need to state that.
>>     
>>     No, we don't. When the callers violate the contract, they cannot
>>     expect to know in detail what will happen. If they want to know, they
>>     will have to read the source.
>> 
>> So you want this to be unspecified or undefined behavior? That might be OK 
>> (we
>> already have that in several places), but we still need to state what the
>> contract is.
>
> You can call it "undefined behavior" if you want.  Personally, I don't
> think that's accurate: "undefined" means anything can happen, whereas
> Emacs at least promises to output the original bytes unchanged, as
> long as the text modifications didn't touch them.

Uh, no?  After converting from utf-8-unix to emacs-internal, Emacs' own
processing will not affect originally bad sequences in utf-8-unix.
However, that would require all string passing to include a
decoding/encoding step so that the nominal encoding used by the module
is utf-8-unix.

I think in the interest of both roundtrip times as well as general
usefulness of modules, it would be better if the default communication
encoding with the module would indeed be emacs-internal.

That way, modules can solve problems outside of Unicode proper.

This is definitely not a no-brainer: choosing utf-8-unix as the
communication encoding for modules would be an interface with less
dependency on Emacs' coding internals but it would pin down UTF-8 as the
only actual useful encoding modules could be made to deal with and would
incur performance penalties.

-- 
David Kastrup