Re: GNU Emacs raison d'etre

[Dmitry Gutov <dgutov@yandex.ru>]

On 13.05.2020 23:05, Karl Fogel wrote:
> Use of small symbols to indicate state in the modeline is another area.  Experienced users know what "**" in the mode line means, what "%" means, etc.  Newcomers are frequently confused by the mode line; it is noise to them, until they know how to interpret it -- but that takes a bit of investment.  Now, we could provide bigger, more verbose signs of current state -- but then we'd be taking away screen real estate again.
> 
> Another area is the keybinding space and the minibuffer.  Just about every time I have watched a new user use Emacs, I have noticed how frequently they accidentally hit some key combination or sequence and wind up in some weird state that they never meant to be in -- and don't know how to get out of.  Often they have minibuffer prompts sitting around all the time, and are unaware that Emacs is asking them for some piece of information (after all, the user didn't mean to put Emacs into that state and has no idea she did so).  But having those keybindings available is*good*  for experts, as we know from personal experience.

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.

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.

> 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.

And unfortunately, in practice around here "prioritizing invested users" 
somehow turns out to mean "let's not make existing users uncomfortable". 
By changing defaults, introducing new workflows, or changing old ones. 
Which, in the long run, serves neither crowd.