emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Emacs raison d'etre


From: Karl Fogel
Subject: Re: GNU Emacs raison d'etre
Date: Thu, 14 May 2020 15:29:35 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

On 14 May 2020, Richard Stallman wrote:
>  > So I suggest that GNU Emacs's raison d'être is to be the text
>  > editor that best rewards sustained user investment.
>
>I would say that this is one of the virtues of Emacs -- but I would
>not call this the raison d'être.
>
>I think that the investment needed is a downside.  The upside is the
>return you get for that investment.  If we could make Emacs give you
>the return without the investment, that would be even better -- but we
>don't know how to do that ;-(.

I think that is impossible in the general case, and would therefore not be a 
good goal to aim for.

Naturally, Emacs should give whatever returns it can give that don't require 
investment.  But that just gets us to the point of making tradeoff decisions.  
Emacs has already consumed a lot of the available space in that "for free" 
region -- I'm sure there's still some space left to grab, and no one here would 
argue against grabbing it, but those are the easy calls.  They aren't 
controversial and they don't require much discussion.

The principle I suggest -- calling it a "raison d'être" may be too strong -- is 
for guiding the decisions that *can* be controversial because they involve 
tradeoffs.  This is most decisions.

Specifically, I'm arguing against assuming that making Emacs easy for new users 
is, in itself, a good idea.  It's really only half an idea.  Discussions about 
how to make Emacs "easy" for "new users" can only be productive if we know 
where we're trying to bring those users and what level of investment we expect 
from them, and if we weigh the costs as well as the benefits of changes that 
favor newcomers (when those changes have negative consequences for experts -- 
i.e., when those changes are not in the "free space", which most changes 
aren't).

(I wish I'd kept notes from the in-person Emacs teaching I've done over the 
years.  Having such notes would be useful right now.  Instead I must rely on 
memory of repeated experiences.)

Best regards,
-Karl



reply via email to

[Prev in Thread] Current Thread [Next in Thread]