Re: Dynamic loading progress

[Eli Zaretskii]

> Cc: Stephen Leake <address@hidden>,
>  Tom Tromey <address@hidden>, Eli Zaretskii <address@hidden>,
>  Emacs development discussions <address@hidden>
> From: Daniel Colascione <address@hidden>
> Date: Thu, 22 Oct 2015 15:52:58 -0700
> 
> >     * expose fast read-only string access (not sure how do-able this is
> >     considering the encoding problem)
> > 
> > 
> > If the internal Emacs encoding is not defined, then we probably
> > shouldn't expose it to modules. What should modules do with such string
> > access? They could only treat the contents as opaque byte arrays.
> 
> Agreed, although there may be a reasonable case for an API that provides
> direct access to strings that happen to be ASCII (or UTF-8) and that
> runs a conversion otherwise, all transparently.

Not sure what you mean here.  First, the internal representation is a
superset of UTF-8, so if we can provide direct access to UTF-8, why
not let modules access the internal representation?

Second, if by "UTF-8" you mean a unibyte string encoded in strict
UTF-8, then why limit that to UTF-8?  Standard C runtime can handle
many different encodings, including multibyte ones, it is not limited
to UTF-8 (although UTF-8 is easier for certain tasks).  Therefore, I
think access to unibyte strings (a.k.a. "byte streams") should not be
limited at all, and letting modules access multibyte strings in their
internal representation would be a significant bonus we shouldn't
easily give up on.