[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: Thu, 16 May 2019 22:23:27 +0200
User-agent: NeoMutt/20180716

Hi Eli:

I agree a little bit too much here. But...

Emacs is an old program, with users who stay with it for 25 and more
years.  Changing old defaults or making other incompatible changes
definitely annoys at least some of those users, especially since quite
a few people don't track the development, and don't see the changes
until years later, sometimes even after skipping several releases
in-between.  This isn't theory, this is our (and my personal) actual
experience from watching Emacs development.  When someone comes up and
asks why we made a certain change in how Emacs worked for decades, we
should have a good reason, and if we don't, we shouldn't make the
change "just because we can".  That's the price of maintaining and
developing an old and stable program.

My point of view since the beginning of my first email ever in the
mailing list was based in 3 things:

1) Some design choices and limitations in the actual emacs were imposed
due to technology 40 years ago. (keyboard bindings, coding system,
screen resolutions, memory available and CPU, network latency, storage
capacity) but most of them are not issues anymore (at least not in the
emacs scales) so we are limiting the potential of emacs due to issues
that disappeared long time ago.

2) Many new features and functionalities (pure editing oriented) have
been introduced/proved/improved in other editors, and they have proven
to be useful (move line, initial configuration, associative bindings,
specific key combinations like in cua-mode, undo/redo and many

An important part of those functionalities are can be implemented with
Elisp in one afternoon probably because they are just details and some
are already available as external packages, but the changes never arrive
because there are not available (practical) keybindings or because of
backward compatibility.

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

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. 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... so we need to offer some advantage on the first
try over the others to keep the users.

For example, many people use nano just because the basic actions are in
a button bar, so they don't get stocked and they can do the basic stuff
quick and fast, no installation no config needed.

Look at the spacemacs community and how many members are there wrapping
emacs functionalities to behave like in vim...

Personally, I wish people would invest much more time and efforts in
adding new features, and would stop futzing with existing features.
For starters, the former is much more useful for our users than the
latter.  Also, I see many times how a change in existing code to make
some minor improvement introduces bugs, which sometimes are more
significant than the "fixed" problem -- this is expected in a complex
stable program, and is a clear sign that changes of existing code long
since entered the area which engineers call "the limit cycle" --
oscillations that don't converge, i.e. the overall code quality is
quasi-constant.  IOW, we are wasting our own resources for little or
no gain.

I would support that the functionalities go in elpa (I say elpa because
it won't need an initial configuration to be used, just list-packages
and install). Because there will be big chances that some other better
alternatives substitute it (ido -> helm -> avy; isearch -> swiper, etags
-> gtags, vc -> magit, ace -> avy) and looking tto the past... nothing
will be removed never ever from the core emacs code.

Also improve the modules API and support to create packages with C as
with elisp. But add the less possible functionalities in the core if
they are not directly editor related (basic ones) or general enough
(infrastructure / API).

Just give a look how many good packages are in melpa, but not in elpa

If you are saying that those packages are in MELPA because they were
rejected to be included in Emacs or ELPA, then I'd be very surprised
to learn that this is true.  I think the vast majority of those
packages started up with MELPA and their developers never tried to
submit the packages to be included in Emacs.

No, I am saying that there is a reason why they made their work, and
they maintain it, but they don't spend time to put it in the official

reply via email to

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