Re: Emacs Lisp's future

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Paul Eggert writes:
>  > Stephen J. Turnbull wrote:
>  > > The file or application is truly local, provided with the OS or
>  > >      created by the user.  In that case on a well-maintained system,
>  > >      the encoding should be valid
>  > 
>  > It could easily be mixed.  For example, in the Emacs source code
>  > the output of the shell command "grep -r she *" produces some text
>  > that is UTF-8 and some that is 8-bit EUC.  So the shell command's
>  > output is not valid even though all its input files are valid.
>  > This type of thing is not uncommon.
>
> Not uncommon, but no more (and no less) sensible than "zgrep she
> /vmlinuz".  Both commands are useful in some contexts, but neither
> command's output should be thought of as "encoded text" in the sense
> that any codec I know of can handle and produce useful output for all
> of the encodings (or even more than one).
>
> If you're planning further processing you shouldn't allow something as
> mechanical as a codec anywhere near that stuff: you should accept it
> into a buffer as binary, and do your own conversions based on any
> useful heuristics you have.

Binary is quite unpractical when you are working in a locale and the
vast majority of output fits it.  Then you want to have things displayed
according to locale and have that stuff which doesn't fit formatted as
some sort of recognizable escape sequence.

And I am mighty glad that Emacs does that without some "if Emacs cannot
be 100% correct it should at least be 100% inconvenient" rule getting in
the way of getting work done.

-- 
David Kastrup