[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: |
Thu, 09 Oct 2014 13:06:11 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
"Stephen J. Turnbull" <address@hidden> writes:
> Eli Zaretskii writes:
>
> > Aren't you again confusing the application level with the lower
> > "engine" level?
>
> No, you and David are confused. All experience with programming
> systems shows that if you leave security up to the application
> programmers, you won't get enough. Remember, the security of a system
> is equal to the minimum of the security levels of its components.
Annoying and distracting the application programmer is not providing
additional security. It's security theatre.
> In the case of Emacs coding systems, it's as simple as choosing to
> name the conformant coding system 'utf-8, and the non-conformant one
> 'utf-8-with-rawbytes. Why does this excite such <adjective deleted>
> opposition?
So first I let the locale and other mechanisms choose an encoding, then
try getting at its choice of coding system before any prompts appear,
then I convert the symbol to a string, check whether the string ends
with "-with-rawbytes" and append it if needed (let's hope it is in the
right location with regard to "-dos" or "-unix" endings) and
lo-and-behold, I am allowed to read a file. Or network connection. Or
console output. If I don't get that, either my control flow will be
affected, or I will receive falsified data not corresponding to the
input that I can't even check for bad bytes and for which I am unable to
figure out byte offsets of various parts in the input because I can no
longer reconstruct the input faithfully.
"Stuff refuses to work" will lose you more users than "stuff refuses to
secondguess".
Stuff like PostScript files are text files with occasional binary
sections. That's real-world data and dealing with it should not require
preannouncing it every time explicitly.
--
David Kastrup
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/10
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/08
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/08
- Re: Emacs Lisp's future, Mike Gerwitz, 2014/10/09
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/09
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/09
- Re: Emacs Lisp's future,
David Kastrup <=
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/09
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/09
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/11
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/12
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/12
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/13
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/13
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/13
- Re: Emacs Lisp's future, David Kastrup, 2014/10/13
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/13