Re: Emacs Lisp's future

["Stephen J. Turnbull" <stephen@xemacs.org>]

David Kastrup writes:

 > I repeat: that is to be the choice of the application rather than
 > the engine.

Which is what *I* said.

But the engine *should* have a default for convenience of at least
some use cases.  What Mark (AFAICS) and I want is to default to not
emitting broken Unicode.  If the application chooses to do so, it
should do so explicitly.

 > "We know better than the application writer what he wants" is
 > rarely going to work to the satisfaction of all.

Again, I've said that in this thread already.

Finally, note that there's nothing nonconformant about rawbytes in the
internal representation per se.  The Unicode standard is for
*interchange* and says nothing about Emacs buffers.  If TeX is
produces invalid UTF-8 and AUCTeX accepts that and converts invalid
UTF-8 to rawbytes, that's not a problem -- everybody knows what is
going on -- and conformance is a non-issue, since it's all internal.
(I don't claim Mark agrees with this paragraph.  And he probably
doesn't for the applications he envisions, because they are modular
(where Emacs is monolithic), and therefore strings in internal
representation are passed across module boundaries.)

But Emacs should not save that buffer to a file or send its contents
to a network stream, without either explicit permission from the user,
or explicit configuration of the output stream by the application.

Autosaves are another thorny problem.  I suppose they will be handled
by declaring them conformant only to Emacs' needs.