Re: Is Elisp really that slow?

[Ergus]

On Thu, May 16, 2019 at 10:50:45PM +0200, �scar Fuentes wrote:
> Can't resist on commenting two points:
>
> Ergus <spacibba@aol.com> 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
> > EDITOR.
>
> 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
> effort.

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
delete-selection-mode.