Re: GNU Emacs raison d'etre

[Karl Fogel]

On 13 May 2020, Dmitry Gutov wrote:
>I might with agree with you principle, but both examples seem suspect.
>
>First, the "low investment" editors frequently have higher density of
>information in the UI elements that correspond to our mode-line and 
>fringe, margins, etc. Largely thanks to their technical capabilities
>(various-sized fonts, graphics, being able to fit different kinds of 
>indicators together on a "fringe"). So it appears at least in this
>area Emacs has been overtaken purely on technical grounds.

*nod*.  There might be room for improvement in how Emacs uses various visual 
areas, though, having watched many different programmers using many different 
kinds of editors, I think Emacs's mode line actually scores pretty well on the 
indicator front (once one learns how to interpret it).

But in any case, note that these other editors also face this same tradeoff.  
You can see it in Microsoft Word, for example: in recent versions, its default 
startup control panel looks like the cockpit of Boeing 747.  Experienced users 
complain noisily about it (you can find various blog posts and other chatter 
about this on the Net), but this UI change was made so that *new* users could 
find a visual path to anything they might be looking for.

The tradeoff will always be there, even if sometimes there is room for Emacs to 
improve -- i.e., room for Emacs to "get to the tradeoff point", so to speak.

>Regarding the key combinations and the minibuffer, there is no hard
>evidence that our current behavior is supremely optimal. In fact, I'm 
>fairly sure that by being risk-averse and resistant to change, and by
>having no UX experts around, Emacs loses out on some possible 
>advancements in usability. Even expert-friendly ones.
>
>So I would recommend not becoming complacent, or becoming assured that
>workflows you have spent some time getting accustomed to, can't be
>improved.

Absolutely.

But the particular *way* in which we've crowded the keybinding space is 
independent of the fact that the space is crowded, and necessarily must be 
crowded if it is to offer experts the quick access to functionality that they 
want.  Crowding the keybinding space is good for high-investment users and bad 
for newcomers (that's why newcomers to Emacs so often trip accidentally over 
unexpectedly combustible key sequences).  That tradeoff will always be there, 
no matter what the particular mapping of key sequences to functionality is.

So I think my example there holds up pretty well.

>> I could go on.  I've taught many newcomers to Emacs, and often the things 
>> that are hardest for them are exactly the things that are*good*  for the 
>> experienced user.
>> These design tradeoffs cannot be avoided.  It would be a fallacy to
>> think that it's always possible to be*both*  maximally
>> newcomer-friendly and investor-friendly.
>
>The last sentence is sensible, but it's generally beside the point:
>I'm sure we still have a long way to go in both directions.

Very good point: there are some things we could that would get us closer to the 
point where tradeoff decisions are necessary.  But not everything we 
contemplate doing will be in that category.  Some of the things we want to do 
will already *be* at the tradeoff point, and then we will have a decision to 
make.

>> This also suggests that the sorts of features that highly-invested
>> users tend to want -- for example, LSP-based features
>
>LSP is a high-investment feature?
>
>Reminder: it came to us from VS Code, Microsoft's text editor for
>programmers.

Not quite.  What I wrote, exactly, is that it is the sort of feature that 
highly-invested users tend to want.  That is different in a subtle way.  By not 
supplying the sorts of things that LSP would enable, we signal to 
high-investment users that there is an entire area of improvement that Emacs is 
not going to explore.  So while lack of LSP hurts both newcomers and experts, 
it discourages the experts more, because they are looking for signals that 
continued investment will lead to increased reward.

Put another way: LSP is the sort of thing that enables highly-invested users -- 
the kinds of people who write or would consider writing Elisp -- to build new 
functionality into Emacs, perhaps even functionality we cannot predict today.  
While LSP is a good thing for all users, newcomers and experts alike, it 
specifically *rewards* further investment by users who are motivated to make 
(and capable of making) investments based on LSP's availability.  It is an 
expertise amplifier.  When we fail to include an expertise amplifier like that, 
we "bend the curve" -- in the wrong direction.

Best regards,
-Karl