Re: Is Elisp really that slow?

[Ergus]

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

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

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