emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: Mark H Weaver
Subject: Re: Emacs Lisp's future
Date: Mon, 06 Oct 2014 20:10:21 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (gnu/linux)

Richard Stallman <address@hidden> writes:

>     However, I would argue that even in Emacs, string<->bytevector
>     conversions should be strict by default,
>
> What is a "bytevector"?

Bytevectors are packed arrays of unsigned integers < 256.  It is the
standard Scheme data type for performing binary I/O.  String operations
deliberately do not work on them.

In contrast, strings are packed arrays of characters, which in Scheme
are not integers but rather an abstract type representing Unicode code
points.

> How would it relate into Emacs?  Maybe your suggestion is a good one.

Implicit string<->bytevector conversions are needed almost every time a
string is passed to/from the C world, since most C APIs are based on
bytes not Unicode characters.  This includes I/O, command-line arguments
and environment variables (whether reading the ones given to us or
passing new ones down to subprocesses), POSIX file names, interfacing
with most C libraries, etc.

My suggestion is that these implicit conversions should be strict by
default.  IMO, only in specific cases (most notably when editing a file)
should invalid byte sequences by accepted, produced, or propagated.

The reasons are (1) to protect internal subsystems (subprocesses, C
functions linked with Guile, etc) from invalid input such as overlong
encodings, and (2) to catch errors early rather than silently producing
garbage in the face of programming errors.

However, it is of course up to the Emacs community to decide when
conversions should be strict.  Guile can provide both modes of
operation.

      Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]