Re: Is Elisp really that slow?

[Eli Zaretskii]

> Date: Fri, 17 May 2019 14:35:51 +0200
> From: Ergus <spacibba@aol.com>
> Cc: help-gnu-emacs@gnu.org
> 
> >> 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)

We want to do all these editors do, and also all the rest.  That's one
of the Emacs's sale points.

Currently, we have many more features, but in the IDE department we
lag after those "limited" alternatives.  We need to catch up.

> >> 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.

Is an Emacs installation really significantly larger than a Vim
installation nowadays?

> 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.

AFAIK, the GUI is modeled after GTK applications.

But feel free to suggest how to "modernize" it (on emacs-devel,
preferably), I don't think we had such a discussion in a long while.

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

If many users change the GUI appearance, then we should see if those
changes should be made by default.  Hard to say without knowing the
details.  FWIW, most posts about "my favorite config" simply turn off
most GUI features, and we cannot learn much from those.

> 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.

Then I guess you are in a minority.  Certainly among newcomers.

> >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).

In that case, I don't even understand why you brought that up.  Not
having modes comes with a price, and IMO it is not too high.  Once we
all are on the same page about this basic fact, we should stop wasting
time discussing it.  Arguing for a change in basic bindings like C-f,
"C-x C-f", etc. is a non-starter, the community will never agree to
something like that.

> 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).

This is not going to fly, no way.

> Delete redundant bindings like ESC = Alt for prefixes, M-4 = C-u, or
> the numerical prefixes with alt and C and keep only one.

This will cause more keystrokes in some cases.  E.g., if the binding
is Meta-something, the M-digit binding is very handy, and the same
with commands that are Control-something.

> Join similar "opposite" commands like C-o and C-j, or comment
> uncomment to exploit negative prefix for one of them

This is not ergonomic for frequent commands (witness how you exempt
DEL from this scheme), because typing the prefix too frequently is
painful.

Anyway, which other editor does that?  They all have different
commands to DO and to un-DO.

> Reserve one prefix only for user specific functions and recommend
> the packages not to use that.

That's C-c, which we already have.

> 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)

What is which-key.

The idea to be more verbose is an interesting one, but I don't yet see
what kind of implementation do you envision.  For starters, where will
the extra text come from, and where and under what conditions will it
be displayed?

> Actually all vim users are terminal users

Then I don't think we should be too interested in those, when we
describe modernization of Emacs.

> 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.

Emacs does support text-mode terminals, and it does that very well.
But it makes no sense to build the UI on the assumption that most of
our users work on a TTY.  In particular, if we ever catch up on the
IDE front, because text-mode IDEs cannot have many important features
considered a must-have for an IDE.

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

That should be backed up by some statistics.  I don't think it's true,
but even if it is, it just is one result of us lagging behind in the
IDE department.

> >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.

I disagree.

> Compilation errors and warnings are much simple to find that way.

Our compilation-related features make that entirely unneeded.

> 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)

Why would one need to go to a line by its number, when you have
fast-movement commands like "C-u C-u C-n"?

> >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.

That's the price, yes.  But removing valuable features to make the
maintenance easier is IMO the wrong way of solving this problem.

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

Because we are a different kind of beast, see above.