Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 14.05.2020 01:04, Karl Fogel wrote:
> 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).

I think the mode-line is more or less average by today's standards. But 
of course it wins on customizability. The fringes a significantly less 
functional, though. :-(

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

Yes, the tradeoff is somewhere in there, but my problem with the 
conclusion is that it would be really easy to misapply your principle 
(e.g. by saying we don't need fancier buttons, even though we probably 
do, or that the Getting Started guide is good enough and doesn't need 
improvement, and someone should go work on specialized Org-mode docs 
instead).

Making good use of it seems difficult.

The kind of person who *could* make a better judgment in this area is 
someone who specializes on UX. And they are rare guests around here.

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

Are you sure that this particular aspect is _bad_ for new users, though? 
Nobody likes to stretch they hand too far. But I'll grant you this 
point, that Emacs is *somewhat* on the side of high-investment here.

This part is expected of a professional tool, however, and the 
experience for newcomers could be improved without taking away much from 
the "oldies". See the 'transient' package, for example, recently 
proposed for inclusion on emacs-devel.

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

Some of them, probably. At this point, I think, there are still a lot of 
decisions that would bring us closer to newcomer-friendliness while 
keeping no worse high-investment compatibility.

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

I'm glad that we both like LSP, or at least the idea of it.

But it seems these days almost everybody wants it, except for MS Word 
and Notepad users.

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

There are certain aspects where LSP is not exactly perfect: the 
functionality it allows is limited by the protocol, and by LSP servers 
available currently. It's an "ecosystem amplifier", or maybe an 
equalizer even.

I mean, it for sure is great, not to be lagging in language support for 
a whole number of languages where we did before. But there are different 
protocols that allow more powerful extensibility. nREPL, for example.