[922] in athena10
Re: emacs cosmetic changes
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Thu Jan 22 20:19:52 2009
Cc: "andrew m. boardman" <amb@mit.edu>, Greg Price <price@mit.edu>,
Tim Abbott <tabbott@mit.edu>, debathena@mit.edu
Message-Id: <70E681A6-2F18-4F0A-9970-45A3B05DD826@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Anders Kaseorg <andersk@mit.edu>
In-Reply-To: <alpine.DEB.2.00.0901221936050.11108@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 22 Jan 2009 20:18:59 -0500
Content-Transfer-Encoding: 8bit
On Jan 22, 2009, at 7:48 PM, Anders Kaseorg wrote:
> On Thu, 22 Jan 2009, andrew m. boardman wrote:
>> For require-final-newline, though, its lack is clearly identified
>> as a potential screw case for current users and the arguments for
>> punting it seem dubious. Unlike other changes, though, it's not
>> changing user-visible behavior to be Athena-like instead of Ubuntu-
>> like, it's more that it's quietly removing a way for Athena users
>> to hurt themselves.
>
> 1. Teaching users to rely on extra safety nets that we add is
> counterproductive. They will get confused when they install Ubuntu
> on their laptop and Emacs behaves differently.
By this argument, we should punt "delete" too.
It's not about "teaching users", it's about catching them before they
shoot themselves in the foot by not being able to log in.
> 3. The default editor on Ubuntu is nano, anyway. Emacs is simply
> not a user-friendly choice for a first editor, and it isn’t our job
> to try to turn it into one.
All of our documentation refers to emacs, largely because it predates
nano. Nano is also a tty-mode editor. If we teach users to emacs,
they can use the same editor in tty mode and X11 mode (where it has
user-friendly features like a menu bar.) We have put a considerable
amount of effort in making Emacs more accessible to users. It may be
that we should scrap all that and document nano and gedit instead, but
I don't think that's necessarily true.
I agree with the idea that reporting bugs upstream should be the first
priority, but I don't think this translates to "Let users suffer". If
we report something upstream, and it will screw enough users, we
should fix it until it's fixed upstream.
-Jon
