Re: Is Elisp really that slow?

[Eli Zaretskii]

> Date: Thu, 16 May 2019 22:23:27 +0200
> From: Ergus <spacibba@aol.com>
> Cc: help-gnu-emacs@gnu.org
> 
> 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.

It is very hard to discuss this stuff in a useful manner when your
arguments are so abstract.  In general, the (alleged) reason for the
current defaults to be rooted in some obsolete technology, if that
indeed is the case, doesn't necessarily mean those defaults are
invalid today.  The discussion of the defaults should be on a case by
case basis.  I can assure you that if the _only_ reason for having a
default is that alternatives don't work well on obsolete systems,
there's no chance in the world someone will be reasonably against
changing them.  IME, usually there are other significant reasons, such
as incompatibility with Emacs conventions, disruption of keyboard-only
workflows, etc.

OTOH, many, if not all of the features you say were proven in other
editors we already provide in Emacs.  If you are saying it took too
long for Emacs to adopt them, then this is an argument about the past,
which is again not useful IME.

So if you want to have a useful discussion about these matters, I
suggest to come up with specific contemporary examples of features
that illustrate your POV.  Otherwise, these just empty slogans for me,
sorry.

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

Since you didn't say what TEXT EDITOR should entail, it is again very
hard to discuss this claim.  From my POV, we do provide a text editor
OOB: you have the usual arrow keys, PgUp/PgDn, copy/paste by mouse, a
menu bar and a tool bar with items most users will expect, scroll
bars, simple edit commands like delete-char bound to keys users expect
them to be, F1 for Help, RET which indents when appropriate, etc.

If you are saying that these basic features are not enough, then a
useful start would be to come up with a list of additional features
that new users are looking for (but please don't try to make your
point by deliberately making a list of features we don't have; this
list should be the result of either polling users or some kind of
survey of popular text editors).  We could then discuss their
introduction into Emacs in an intelligent way.

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

We will not attract new users by providing just a text editor.  There
are way too many of them out there, and it's very hard, to say the
least, to be significantly better just in that class.  We must find
our own niches, and be one of the top players in those niches.  One of
those niches should IMO be multi-language IDEs, but there are others.

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

Emacs has the same.

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

Doesn't prove anything to me, sorry.  People who like spacemacs should
be free to use spacemacs, but it tells nothing about those who don't,
of whom there's quite a large number, AFAIU.

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

Before we decide where the functionality will go, we should have it in
the first place.  It currently doesn't exist anywhere.  That's the
main problem; the location of the packages is secondary.

> Also improve the modules API and support to create packages with C as
> with elisp.

The main IDE features cannot be implemented in modules.  They can use
some external support functionality via the module interface, but the
features themselves must be in Lisp.  We don't even have a coherent
framework for such features at this time.  CEDET was supposed to be
it, but judging by the fact that no one is developing it, and, on the
contrary, what little development we have in the IDE area is bypassing
CEDET, I'm beginning to think that maybe that decision was a de-facto
mistake.

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

People are welcome to scan MELPA packages and suggest to their
developers to submit them to Emacs.  If indeed the reason is what you
say (and I sincerely doubt that), we will have many of them in
Emacs/ELPA in no time.