Re: Emacs Lisp's future

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     UTF-8 is defined as not containing "overlong" sequences, so Emacs
>     decodes them into two raw-byte indicating characters, one indicating
>     0xC0, one indicating 0xA2.  When encoding, it reassembles them into
>     0xC0 0xA2.
>
> In that case, it might be reasonable to ask the user whether to accept
> a UTF-8 file decoding that contains any raw-byte characters.
>
> What do people think of this?
>
>     One problem with that is that quite often Emacs' choice of a coding
>     system for a buffer is the result of heuristics rather than dependable
>     information.  Not making a fuzz might often be simplest.
>
> Could you explain what "fuzz" means here?

You load a file, edit a line, try saving.  Emacs complains that it feels
insecure doing so even though the line you edited is perfectly fine.
That's getting in the way of doing work.  It would be worse if Emacs
already prompted for approval when loading.

More often than not, the locale applied for operations is not even
explicitly specified but a consequence of the user environment or
preexisting content.  Having internal operations and file read/write
fail depending on the state of the user environment is a nuisance.
That's particularly a danger when most core developers actually use
basic English locales and don't even notice the havoc "locale-awareness"
may cause.

A recurring phenomenon in that direction is generation of number
presentations that can no longer be processed because of being written
under the influence of an LC_NUMERIC setting developers did not expect.

-- 
David Kastrup