Re: Emacs Lisp's future

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> Mark H Weaver writes:
>  > Eli Zaretskii <address@hidden> writes:
>
>  > > Specify, and then drag it all the way down the encoding/decoding
>  > > machinery.
>  > 
>  > The strictness flag should conceptually be part of the encoding, and
>  > thus associated with the I/O port.
>
> This is the way Emacs works already.
>
> However, I think the Python system, where strictness is part of the
> I/O port, not the encoding, and the encodings are designed to error
> and then hand the invalid raw bytes to the error handler if desired,
> is a better API.  I don't know how easy it would be to provide this in
> Emacs

Emacs uses CCL programs for encoding/decoding.  It would be a
performance disaster for loading files with binary parts (like
PostScript) to break out of the CCL program for every "invalid raw
byte".

I cannot believe this, really.  We _fought_ all the Emacs 20 encoding
wars decades ago.  It looks like a bunch of armchair strategists trying
to reinvent the wheel but these are actually people fundamentally
involved with the original efforts.  Which makes this doubly as
baffling.

Richard was _part_ of the Emacs 20 efforts and basically the one who
forced the MULE issue, and Stephen was on the XEmacs side which now has
ailed in popularity not least of all because Emacs tends to work better
in practice _now_ regarding the current prevalence of multibyte codings
in spite of XEmacs being earlier in aligning itself internally with
utf-8 (If memory serves me right).

I can understand GUILE developers being unaware of the experience we
gained through all those years.  But I am baffled at those who _led_ the
respective efforts wanting to repeat history, persuaded that everything
will be different next time round.  Actually not even that: it would
appear that our history and experience are not just treated as
irrelevant but rather as non-existent.

This thread is called "Emacs Lisp's future", but we seem determined to
plan this future starting in 1994 rather than 2014.

-- 
David Kastrup