Re: Emacs Lisp's future

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > There's also the case that the application was invoked on a remote
 > host, and its output is passed via the network (a.k.a. "Tramp").  Not
 > sure if those 3 cases cover that.

My three cases were intended to cover the "local" case, where the user
presumably has control of the files on her system.  The case you are
describing is covered under network streams as far as I'm concerned
(YMMV, that's just the way I broke things down).

 > > An example of (3) is David's case, with AUCTeX handling of TeX error
 > > messages containing non-unibyte text.)  AFAIK such applications are
 > > quite rare nowadays.
 > 
 > "Rare" doesn't mean unimportant to users to the degree we can ignore
 > them.  If we do want to cater to those "rare" cases, the only way of
 > doing that is maintain a database of programs and their behaviors.

That's my main strategy, yes.  We have `file-coding-system-alist' for
filename cases, similar features for process and network streams, and
individual modes such as AUCTeX are developed by hackers who have
proved themselves able to take care of themselves.  Emacs can also
provide a way for individual users to opt out of the default
validation mode persistently (eg, provide a global default variable
and use novice mode for the opt-out).

 > Moreover, I don't think case (1) is as easy as you seem to think.

Eli, I live in encoding hell, aka Japan, and have to deal with Chinese
as well (Chinese students often use GB encodings to write Japanese).
Please give me credit for extensive experience with not only broken
implementations, but also bloodyminded standards bodies and users only
half as witty as they think they are.  Nevertheless, things are much
better today than in the days when Erik Naggum declared that "Emacs
has a fatal disease, and its name is 'MULE'".

 > In many cases, a file or a program that you think are "local"
 > really aren't.

Just because a user thinks it local doesn't lower the risk associated
with networks, although it may be somewhat lower than the open
Internet.  This is in the same risk class as other network streams.

I suppose it would be reasonable to distinguish between Internet
streams, local network streams (but only if a valid certificate was
presented, otherwise there's little reason to be confident), and local
files or processes.  But doing that conveniently and accurately sounds
like a painstaking task.

 > > I understand David and Eli to be of the opinion that in practice there
 > > is insignificant risk to Emacs or its users from any form of invalid
 > > or malicious input, from the network or local.  I disagree.
 > 
 > I never said anything like that.

No, you didn't.  I infer it from the policies for Emacs you advocate.

 > What I did say, and stand by, is that doing what you suggest is
 > certain to cause user outcry of the kind I remember very well.

It won't.  There may be outcry, but the world has changed dramatically
from the times you remember, and the outcry will be different (except
for users like yourself who were there at the time and will be upset
by the "regression"[1]).

 > I think it's naive to assume that "this time it will be different";
 > experience has taught me that this attitude is ill-advised.

I don't assume it.  I know for a fact that the world is much more
hostile than it was back then, and I think other conditions have
changed enough that it's time for another experiment, hopefully with a
little bit of attention to design of user interfaces in advance.

 > We shouldn't do that out of our own initiative based on academic
 > considerations and examples from PHP or whatever.

You think spam, viruses, phishing, buffer overrun exploits, and the
like are "academic considerations"?

They aren't, and the attitude that users can and should take care of
themselves is *not* a selling point in this environment, except for
developers who would rather not deal with complex APIs and worse, the
finicky art of providing convenient, unobtrusive, and yet flexible UI.

Footnotes: 
[1]  And I hope that group is a tiny minority, given the rapid growth
in computer usage in just that decade and a half.  If it turns out
that greybeards like us are the majority of users, that's a sad day
for Emacs and for free software.