[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
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, David Kastrup, 2014/10/11
- Re: Emacs Lisp's future, David Kastrup, 2014/10/09
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/10
- Re: Emacs Lisp's future, Andreas Schwab, 2014/10/07
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/06
- Re: Emacs Lisp's future, David Kastrup, 2014/10/06
- Re: Emacs Lisp's future,
Mark H Weaver <=
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/07
- Re: Emacs Lisp's future, Florian Weimer, 2014/10/11
Re: Emacs Lisp's future, Richard Stallman, 2014/10/05
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/05
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/07
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/07
- Re: Emacs Lisp's future, David Kastrup, 2014/10/08
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/08
- Re: Emacs Lisp's future, David Kastrup, 2014/10/09
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/09