Re: Dynamic loading progress

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Cc: Philipp Stephani <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden
> Date: Sun, 22 Nov 2015 21:59:43 +0100
> 
> > 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.

That's exactly what I am proposing.

> 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.

No!  Modules cannot convert non-ASCII text into emacs-internal (we
don't expose the coding.c functionality through the API), and
shouldn't have to.  That is the job of the interface.

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

What problems are those?

> 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.

That's exactly what's being proposed.  But utf-8-unix is NOT the
internal encoding, it's the Unicode-mandated UTF-8.