[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: Wed, 15 May 2019 01:54:12 +0200
User-agent: NeoMutt/20180716


Sorry I lost the most recent messages because the mail engine disables
my account very often.

OK, point taken. Users, newcomers, aren't
impressed by Emacs. The don't dig the console
and they use the mouse. And they want
everything integrated, all tho, which is
amusing, integration is limited to
a single language.

Not only that, see below.

(Maybe MS IDEs can do all of C#, VB(A), and
MS Access now that I think about it...?)

Yes they can, VS code supports many of them, butt especially the most

OK, now it gets totally confused %) The
different language major modes are the absolute
_backbone_ of Emacs as a programmer editor,
indispensible! Obviously we want them for every
conceivable language to be as good as possible!
Setting up font-lock and indentation for
a programming language major mode (which even
I have done BTW) isn't what I thought we
were talking about rather much more advanced
stuff, the refactoring stuff (how ever that
works), integrating the debugger and build
process, and so on, and as for
language-specifics, qualitatively different
stuff, not just configuring and tweaking with
the same old interface!

This is something even advanced compared to a real integration we need
like unify commands bindings, interfaces and functionalities names.

I go every time to the same topic here, but all the time I only receive
complains and strong answers with strong feelings from the older
users. We NEED to update the interface (unify the bindings for all the
languages, unify packages with similar functionalities, delete unused
functionalities.) It is not a should, it is a must.
To mention just one example: It does not make sense that C-c C-c
comments the current lines in C-mode, but sends the current sexep to
terminal in other modes, or send the messages in others. So emacs
somehow behaves as a different tool/editor for 3 different modes, so the
"unified bindings/behavior" is not an advantage anymore.

Or that we provide several options (or packages) to add parents with 300
customizable variables but a very bad default behavior. The existence of
spacemacs ergoemacs and other similar customization is a user's scream
for better defaults (I am not telling to ennable all what spacemacs
does, but we have functionalities that the users will never discover if
they don't go in the ddeep parts of the manual).

Usually the old users (who deserve the legacy behaviors), are also the
most skilled ones, so it is easier for them to add some lines to their
config, than for new users that we don't want to scare the first day
with Lisp.

This argument doesn't fly with users, because
newcomers usually need just one language, but
they need a good support for it. They will go
away if we don't have it, and telling them we
support a dozen others will not make them
change their minds.

Sometimes new users also mix languages, but the worst supported ones are
the newer languages (Lua, Julia, Ruby, Python, C++ 11+, Rust) Which are
also what they need more often.

To keep Emacs alive and kicking for the
observable future, we need to be sure we will
have enough developers and contributors.
And since developers and contributors start
as users, we want to attract new users. If we
fail to attract them, we will quite literally
lose our future.

OK, good point.

But also there is the fact that we are spending a lot of
effort/work/manpower in specific use cases and fancy functionalities
(web browsing, pdf reader, image shower) instead of looking and
prioritizing the general and basic editor functionalities (faster
movements commands, default bindings for comment/uncomment, select whole
line, infrastructure performance). So going to the specifics instead of
the generals.

AFAIR emacs started (and became popular) cloning the popular
functionalities in other editors and making them accessible with simple
We just need to open sublime or athom or VS code and look all the
functionalities they provide for EDITING TEXT 2 clicks (or key binds)
far. That's the real reason of their success. Basic functionality out
of the box.

What happens now is that if a user wants a simple editor with
indentation support and syntax highlight for multiple languages, they go
for vim (it is there already, is small and has many commands for editing
text quickly, and the learning curve is similar than for emacs and much
faster/responsive). Else, if they want something advanced, then they go
for an ide or a simpler (more familiar) editor that they can start using
without reading or configuring anything, geany, athom, sublime, visual
studio code. But if the project is big with autotools or cmake they just
go for a bigger ide like kdevelor, qtcreator, eclipse, NetBeans with a
better autocompletion, debugger, compiler, packer.

Lets say for example: sublime is extensible with a simpler language
(than (lisp)) that many people use these days, it is pretty by default,
and supports many languages. It works good enough, the code is on
github, the issues, pull requests and collaboration in general is
without an arcane mailing list, and a familiar fork-joing approach. So
from the point of view of a 20 yo developers "why to us emacs?" (It is a
rhetoric context question, please don't reply to it in your answers)

So the good thing is that emacs can provide all this, but is doesn't to
have all that working it needs years (literally) of
configurations/packages. Is that what a user will chose having easier

Well, obviously you worked on much bigger
projects than I, but I did a university project
(check out the URL in my signature). The report
- compiled LaTeX and Biblatex, which I wrote in
Emacs - is 153 pages. I used C++, Lisp, zsh,
gnuplot, groff, and pic(1), and wrote all of
that in Emacs. Even the Makefile and several
textfiles :)

So how large should a project be before Emacs
becomes insufficient? A Quake? If so, then no,
regretfully I wasn't part of the team...

The problem is that (in my opinion) we lost the center of what emacs
should be and where are the practical-sustainable-maintainable limits a
long time ago (the difference between "we can" vs "we should").

The program grow an grow and grow and the
unused/old/substituted/unsuccess functionalities weren't deleted.

(We added the GUI over the TUI mixing everything and adding support for
every single detail we could imagine, multi os support forced to
implement everything generic.) And as a plus the Elisp language and
interpreter, two more things to maintain and update.

To maintain-support all that with (every time) less people, we have
abandoned (not improved) the editor-ide functionalities, and the world
continued moving in the mean time. (Also some needed changes have been
delayed and arrived veeeery late because "we shouldn't convert emacs in
the other editors" or similar opinions.

So, as usual in technology, other products filled the hole thinking in
the final user and not in the developers. So, in spite of our product is
better we don't find users for it because we don't know how to present
it to the new market.

reply via email to

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