emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Lisp's future


From: David Kastrup
Subject: Re: Emacs Lisp's future
Date: Tue, 07 Oct 2014 18:16:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

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

> Richard Stallman writes:
>
>  >     To put it another way, Mark said that Guile is intended to be useful
>  >     writing servers as well as interactive programs.
>  > 
>  > This discussion is about Guile in the context of Emacs specifically.
>  > "What Guile does" generally is a different, though related, topic.
>  > Guile could follow the Unicode spec in normal operation, but offer
>  > another mode that Emacs can use.
>
> It *could*, but it for the default is entirely unclear to me that it
> *should*.  Some use cases, such as AUCTeX parsing error messages from
> TeX (which treats content quoted from the document as bytes, and so
> may slice characters into two invalid byte sequences), will use some
> sort of reversible encoding of raw bytes (the current Emacs encoding
> is one option, of course).  But they can do that explicitly.

Not really.  The terminal/log output will in general reflect the
encoding of the source document and it is human-readable, so you want
the output filter to generally decode as utf-8.  Now TeX may indeed
choose to slice multibyte characters in two (for example, because it
inserts newlines in its output every 79 bytes).  Parsing the error
messages properly requires the ability to reconstruct the input before
the output filter decoded it.  Neither having the output filter pass
everything as bytes (that will make the output generally unfit for human
consumption rather than just in single places) nor "sanitizing" it (that
will make reconstruction of the original context impossible) are
satisfactory here.

The "I know you don't want me to produce anything other than utf-8
anyway" attitude is just getting in the way of such application needs.
Sometimes things are messy, and it must remain the application's choice
how it wants the mess to be dealt with.

> However, in general I think that Emacs should help users who are naive
> about Unicode to avoid emitting invalid Unicode, and so should default
> to querying the user for permission if that were about to happen.  It
> should not silently pass on corrupt input to the output.

You are confusing Emacs with the applications running on it.  It is not
the job of an engine to make the decisions for an application.  In
general, an engine should deal with the problems you tell it to deal
with.

-- 
David Kastrup



reply via email to

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