Re: Is Elisp really that slow?

[Eli Zaretskii]

> Date: Fri, 17 May 2019 07:52:02 +0200
> From: Ergus <spacibba@aol.com>
> Cc: help-gnu-emacs@gnu.org
> 
> The problem comes when people needs to configure everything because the
> defaults are terrible

Please don't exaggerate like that, it makes the discussion more
emotional and less useful.  Our defaults are not "terrible" by any
account, certainly not when expressed in such a general form.

> Vim [...] is the only editor that worth to compare with emacs.

I think you are wrong here.  There are VSCode, Atom, and a few others.

> It is easy to explain and I have refereed to this in many maaaaany other
> emails:
> 
> 1) vim is there in all the GNU/Linux distros.

Not much we can do about that.  Feel free to lobby distros to include
Emacs.  IMO, if something is related to 40-year old decision, it is
this one.

> 2) It works the same in all the systems, in all the languages, even the
> default color themes are better by default.

Emacs also works the same on all systems.  As for "better default
colors", that debatable at best.  It's a matter of taste, and
psychologically we tend to favor our first experience: old habits die
hard.

> 3) The keybinds (apart from the insert-escape) are easier, more
> ergonomic and logically composable.
> 
> 4) It is extremely responsive and fast to open-close workflows. No
> lagging, or delays, no server configuration needed.
> 
> 5) The important editing commands are usually only 1 key far. We can
> make a simple comparison:
> 
> Move forward: C-n -> j
> Move forward 3 lines: M-3 C-n -> 3j (look sparsity in the keyboard)
> Copy 3 lines and return to point position:
> C-SPC C-SPC C-a C-SPC M-3 M-w C-u C-SPC C-u C-SPC -> 3yy
> 
> Plus:
> hjkl are way more ergonomic than what we have (you can type them
> with one hand, while the other types the prefix, but they are also
> together, so going 3 lines up 5 letters left is way faster and easier) 

If you want to argue that Emacs should be a dual-mode editor like the
vi family, and that this is your "future", then we will never agree.
One of the revolutions that Emacs brought to text editing was its lack
of modality, where you just type text to have it inserted.  Dual-mode
editors are a thing of the past in my eyes, a remnant from the old
days when editors didn't have the real-time display, where you needed
to have commands like "move N lines from the current one, then delete
M lines" etc.  Please don't even get me (and others) started on this
"feature".

> Plus:
> In vim the user can enter complete lines/commands/functions:
> 
> :e file
> :8,10 s/search/replace/g

How is this different from Emacs's "C-x C-f" or M-% in the selected
region?  Are you saying that it's easier to remember ":e" than "C-x
C-f"??

And you contradict yourself here: simple text editors all provide
operations on the selected portion of text.  Emacs does that, while
vim tells the users to remember the cryptic "N,M s/foo/bar/g" stuff
that goes back to the 50-year old ed(1) and sed(1) editors!

> which is more intuitive and familiar for terminal users.

"terminal users"? who are those?  what's a "terminal"?  Are we really
going to target 70-year old curmudgeons that still work on a
'terminal"?  why? because vim does that?

Forgive me, but this is all backwards!  Modern users want first and
foremost GUI editors, because you can do in GUI display stuff that is
unimaginable for text-mode environments.

> Plus:
> There are no conflicts with the modified inputs and the terminals, so
> they have more keybindings to use.

Yesh, and you pay by having two modes.  No, thanks.

> 6) They do one thing and do it well. Editing functionalities have
> priority (for example column indicator or line numbers were added very
> long time ago.) 

Line numbers are a _must_ in vim, because so many commands _require_
you to name the line numbers.  See your example above.  That Emacs
originally didn't have line numbers is because you don't actually
_need_ them so much.

> 7) I understand it is also much simpler than emacs in functionalities,
> but that is a benefit from the maintenance and update point of
> view. They don't need to maintain an interpreter, their own language, a
> graphical and a terminal interface, different modes for every
> programming language, wrapper functions for terminal commands like grep
> (or version control functionalities) a browser, file manager, a server
> interface and client, a network infrastructure... This also means that
> the number of programmers and expert fields they need to maintain all
> the code is also smaller.

This also means that you can never have a MUA in vim, or an IDE, or a
debugger front-end or anything even remotely similar to Org.  Let the
people who want simplicity at a price of a limited editor use vim.  It
is not them that I think we should attract.

> I am NOT making apology of vim, I am just pointing how are they doing
> and why they success more with a "worst product" because it is not a
> mystery.

We don't _want_ success of the vim type.  That's the wrong type of
success for Emacs.

> >Maybe, just maybe, having "kill & yank" instead "copy & paste" is not
> >the cause of Emacs' lack of appeal to the new generations.
> >
> 
> It is one more.

Excuse me, but this is nonsense.  Our menu and tool bar say copy/paste
for at least 20 years, as do the manuals.  I wonder when people will
stop beating this dead horse.