Re: Is Elisp really that slow?

[Ergus <spacibba@aol.com>]

On Fri, May 17, 2019 at 12:01:54PM +0300, Eli Zaretskii wrote:
>> 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.
>
Sorry then. But I am getting tired.
>
>> 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.
>
Yes, but they are very different and limited in many sense. VSCode
extensibility is very limited. And they don't work in terminal, which is
my base starting point (because some limitations comes from there)
>
>> 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.
>
I did actually some time ago and some distributions just replied that
the community was too small and the package too big compared to vim, but
it could be easily installed from repositories bla bla bla.
>
>> 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.
>
The gui could look much modern with a couple of lines in the
configuration. But the first impression now is like a program in windows
95.

This is something that an emacs user changes in 10 minutes probably, but
for a new user is not trivial.

The gui interface is not important at all for me. This is one of the
very simple changes that could take 5 minutes to do and 3 months arguing
in the mailing list.
>
>> 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".
>
I don't use vim due to the modes. I literally hate the modes. But on the
other hand npbf are too sparse and between some keys that modify the
buffer when Ctrl is hold (ojd).

My real proposes (if any, which is not actually) would be to change
those basic ones with jkli, or asdw (it is just an example). Delete
redundant bindings like ESC = Alt for prefixes, M-4 = C-u, or the
numerical prefixes with alt and C and keep only one. Join similar
"opposite" commands like C-o and C-j, or comment uncomment to exploit
negative prefix for one of them (so we free a bind and standardize
somehow, except C-d and DEL). Reserve one prefix only for user specific
functions and recommend the packages not to use that. Enable some extra
verbose features when there is not any configuration file and not using
-Q (because it is a hint that probably it is a new user or an old user
in a foreign machine) (I mean which-key for example)

>> 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"??
>
Once we entered C-x C-f (which is actually longer and with no
associative relation) it is not possible to change mind, go back and do
the equivalent to C-x C-v or C-x 4 f (without C-g reenter the new bind
and reenter the file). With a ":command argument" it is more familiar
for terminal users and is possible to add modifiers to the commands (to
easy standarization and reduce memorized bindings)... Add finally an undo
and redo, even if it is optional. but have some binding for both.
>
>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!
>
I don't complain about our approach in replace (with transient-mark-mode
of course, and there are suggestions there) it was just an example of a
very complex command that vim users love for some reason but it is
composed by many pieces that work independently with logic, no memory.
>
>> 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.
>
Actually all vim users are terminal users, so they are not quite a few
these days, specially on GNU/Linux. Server management, remote access,
embedded systems, and core hardware pieces with Linux kernels (routers)
raspberry pi and single board computers, High performance clusters don't
have GUI. The terminal emulators are still the most popular and
important part for GNU/Linux users. And those systems actually are more
used in servers than desktop. And looks like it will be like that for a
long time.

The gui support is a good move, but most of our potential (short-medium
time) users are terminal dependents.

Packages like i3wm, bash, zsh and low level GNU/Linux distributions
(like arch) are very popular.
>
>> 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.
>
I know, I am just pointing out one of their advantages over our design
limitations. I really hate the modes.
>
>> 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.
>
For programming it is a must, actually. Compilation errors and warnings
are much simple to find that way. Also, going to a line is the kind of
command that must have only a 2 keys binding by default (and probably a
behavior like goto-line-preview by default)
>
>> 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 mention this because there is too much code to maintain and of course
we can't do the best in all those fields. There are external packages
(compilers, text web browsers) that at some point we will need to trust
them and rely functionalities on them. And other functionalities could
be unified (like grep, rgrep and so on to a single general function to
call all shell commands and produce the same outputs (we already have
that, but still specialize to produce occur like buffers))
>
>> 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.
>
Why?
>
>> >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.
>
In reply to the other email... I proposed to do a survey and
functionalities interest question a long time ago in the developers
mailing list. I even proposed some initial questions to do. Sent the
link of some pages to publish that and finally nobody cared.