emacs-devel
[Top][All Lists]
Advanced

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

Re: What is the most useful potential feature which Emacs lacks?


From: Karl Fogel
Subject: Re: What is the most useful potential feature which Emacs lacks?
Date: Wed, 27 May 2020 23:00:49 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

On 14 May 2020, Richard Stallman wrote:
>  > User does `C-x C-f' to find a file, but they hit Return at the
>  > wrong moment while typing the file path, causing a Dired buffer
>  > comes up visiting the file's directory.  The user is, of course,
>  > totally baffled by this result.  And yet it's obvious why this is
>  > a good default behavior for `find-file' -- for people who
>  > understand what's going on.
>
>This is a useful observation.  How can we arrange to inform users
>about this at the right time?
>
>One idea: the first time a user tries to specify a directory in find-file,
>display a help screen to explain what that means, and describe a few
>usual ways out.
>
>Do you think this would ameliorate the problem?

My guess is it would ameliorate the problem for some users, and scare off other 
ones (ones who are less patient, or, put another way, who are less willing to 
invest time in reading an explanatory screen like that to figure out what just 
happened).

>    > If we just say "Emacs should be easier for newcomers to learn",
>    > that's not a useful rallying cry IMHO.
>
>I think it can have a practical benefit -- if it motivates people to
>observe beginners' stumbling blocks as you have done, and then to study
>how to help beginners cope with them.

The danger I am worried about is a change that simultaneously makes Emacs 
*more* approachable for the type of newcomer who isn't inclined toward 
investment but *less* rewarding to the type of user who is.  When we face that 
tradeoff, let's optimize for the second kind of user.

Obviously, changes that give the former benefit while not incurring the latter 
cost are non-controversial and we should all be in favor of them.  (How hard 
they may be to implement is a separate question.)

>What other frequent points of confusion have you observed?

Well, there are a bunch; the next time I'm helping a newbie I'll try to watch 
and keep a list.  I think I've posted the main ones that I can easily recall.

None of this is a criticism of Emacs, by the way.  The Atom editor, for 
example, seems to be a lot friendlier for newcomers, at least when I watch them 
use Atom.  On the other hand, I have yet to see anyone -- newcomer or 
experienced user -- using Atom to do text manipulation anywhere near as fast 
and fluently as an experienced Emacs user does.

One major source of these observations for me has been the regular Tuesday 
night in-person gatherings in Chicago at https://chihacknight.org/.  
Unfortunately, those are not happening in person right now, of course, and no 
one knows when they will resume.  For the same reason, it will probably be a 
long time before I have a chance again to observe newcomers editing (in any 
editor) in person.

>It could be useful to make a list of those, and we could
>try to work on each of them over time.

Making such a list is not easy, but if I get a chance to do it I will.

>  > If we say instead "Emacs should try to attract newcomers who have
>  > a higher-than-average probability of becoming high-investment
>  > users, and should explain early on to those newcomers what the
>  > road ahead looks like"
>
>We should do that, but not by exaggerating.

As I reiterated in some other posts: I wasn't exaggerating.  Emacs is more 
daunting for newcomers than other editors, and its dauntingness is connected 
inextricably to its power -- to the path by which it rewards investment.

I believe that for most users, Emacs really only starts to pay off after more 
than a year of regular use.  By "pay off", I mean something quite specific: I 
mean reaching the point where one can, on average, accomplish one's tasks 
noticeably faster in Emacs than one could have in some other editor had one 
spent that year learning that other editor instead.  

This was my own experience, and it's what I've seen happen with others.  Now, 
I'm sure there are exceptions: if someone spends a few months *intensely* 
learning Emacs, especially with in-person help, they'll surely learn as much as 
some other person might have learned in a year or even more.  If I were to quit 
my job and practice piano all day long, I could get pretty good pretty fast too 
:-).  But I'm talking about the common case: of users who today are fluent 
Emacs users, I think (though based on anecdata) that most of them took more 
than a year to get to the point described above.

(I'm assuming vim is not the "other editor" in the above scenario, since vim 
too is extensible and very much oriented toward rewarding sustained investment 
-- and, no coincidence, fluent vim users do things at least as quickly as 
fluent Emacs users do, as far as I can tell.  I've sometimes heard that 
Microsoft Visual Studio Code can be the same way, but I've rarely had chances 
to observe experienced people using it, so I can't say.)

Best regards,
-Karl



reply via email to

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