[Top][All Lists]

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

Re: Is Elisp really that slow?

From: Ergus
Subject: Re: Is Elisp really that slow?
Date: Fri, 17 May 2019 00:46:11 +0200
User-agent: NeoMutt/20180716

On Thu, May 16, 2019 at 10:50:45PM +0200, �scar Fuentes wrote:
Can't resist on commenting two points:

Ergus <address@hidden> writes:

3) The development is not focused in the first thing that a user needs
when she opens emacs: provide the most comfortable and useful TEXT

For many people this is Notepad.

Or notepad++, or sublime text.

If emacs as TEXT EDITOR does not convince them (just the first try,
without config, without reading the manual/tutorial/documentation), then
they will not even try any other functionality.

Indeed, Emacs has a non-negligible learning curve. Other editors do a
lot out of the box in a familiar way, but then you hit the wall. Emacs
is lacking in out-of-the-box functionality for modern programming
languages but otherwise, as a pure editor, it has no walls.

I agree 50% here. One thing is to use specific emacs functionalities
tricks, but another one is when you don't know how to start, because the
workflow is orthogonal to 90% of everything else, or you look for the
word copy and paste in the tutorial you only find kill and yank.

The first impression is actually the most important. And if a user don't
see any advantage the first 10 minutes, we lost him.

I think that you are one
of the few in this list who sees the importance if attracting new
users/developers. Unlike vim; emacs is not in the gnu/linux distros, it
is slower and bigger...

Are you sure? emacs -Q is instant here, vim grew quite a bit and,

But with the -Q option you will have precisely all the defaults that
most of the people end changing because we don't do for them, without
extra plugins or extensions... so... when fast no advantages...

anyway, who cares about a few dozen MB of difference when some of the
modern contenders use GB of *RAM* to work?

There is actually a thread complaining about the emacs size in windows

so we need to offer some advantage on the first
try over the others to keep the users.

Emacs provides some advantages, but they are not apparent until you
experience them.

That has nothing to  do with the fact that the apparent ones could be
better and they are not because of inertia.

That's a problem for people grown on a culture of
instant gratification. Emacs appeals to certain type of users who
understand that gains require efforts.

Here agree, but the spectrum must be opened. We are not in 1990 anymore.
The really big problem is that
Emacs no longer compete on areas were it used to bring the largest
gains. Other editors largely surpassed Emacs' gains while requiring less

This is exactly the key of all my point. We can't continue patching and
putting works around to this issue and we can't compete and win in all
the fields we cover, so at least we must be centered in one of them, the
most important one. Compete in the main goal, the main objective... And
as simple and logical for the users as possible. It looks illogical for
me that fill-columns-indicator or line-numbers came into emacs in
version 26.1 and 27.0 being so basic functionalities for any editor. Or
that we don't have at least a native-simple undo-redo (even if it needs
an extra line to be enables in the configuration file). Or that there
were so many discussions about enabling transient-mark-mode, or

reply via email to

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