Re: Emacs Lisp's future

[Mark H Weaver <mhw@netris.org>]

David Kastrup <dak@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: David Kastrup <dak@gnu.org>
>>> Cc: rms@gnu.org, mhw@netris.org, dmantipov@yandex.ru,
>>> emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca,
>>> stephen@xemacs.org
>>> Date: Thu, 09 Oct 2014 09:52:31 +0200
>>> 
>>> I still don't want the autosave of mail to complain about bad
>>> characters.
>>
>> We write the auto-save files in the internal format, so it never
>> complains.
>
> If you are not allowed or able to do that...  At the current point of
> time, the only round-trippable encoding for bytes that GUILE offers is
> latin-1, and the only round-trippable encoding for characters is utf-8.

"Not allowed"?  Another strawman.  I guess it's a waste of time for me
to say, yet again, that we'll support the "raw bytes" encodings, because
you'll just keep on pretending that we won't allow it.

> The conceptual lack of separation between internal and external utf-8
> encoding leads to strangenesses like
>
> scheme@(guile-user)> (with-input-from-string "\ufeff!" read-char)
> $8 = #\!
>
> Yes, this is a string->string operation losing a byte order mark in
> spite of no indication that I would like to get encodings involved in
> any manner.

Byte Order Marks are an ugly corner of Unicode, and I spent a lot of
effort to try to do the right thing here.  What we do in Guile is
described here:

  https://www.gnu.org/software/guile/manual/html_node/BOM-Handling.html

I agree that we should inhibit BOM handling for string ports.

> And when I can say "let's see where this kind of thinking will lead" and
> find a hole to poke within a minute,

BTW, your claim that you found this hole "within a minute" is a
bald-faced lie and you know it.  In <http://bugs.gnu.org/18520>, I
stated my belief that our internal use of UTF-8 in string ports was not
visible to the application as long as you didn't manually change the
encoding for the string port or use seek/ftell.  That was on Sept 24th.

You spent a *lot* of time arguing with us in that bug report, and this
is exactly the observation you could have used to bolster your argument,
but you never found it until now.

      Mark