Re: Is Elisp really that slow?

[Emanuel Berg via help-gnu-emacs <help-gnu-emacs@gnu.org>]

Eli Zaretskii wrote:

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

That's exactly right: the past is the past and
nothing can be done about it. The future will
come when it comes, no doubt. So only the
present is up for grabs! So get as good and
meaningful a grip as you can, I'd say.

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

But: we have already found our own niche, and
that is to be *everything*. This explains why
we aren't the best at every little programming
language out there. That would mean to be
superhuman - which (except for the X-Men)
is impossible.

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

It is much easier that way, most definitely.

> [...] disruption of keyboard-only
> workflows, etc.

And that in particular we never want
to disrupt! :)

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

...? Is this the definition of a text editor?
If so, perhaps we should come up with another
category name for Emacs...

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

...? Cannot there be Lisp modules? What
"module interface" or type of module are we
talking, exactly?

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

CEDET - ah, yes, I've heard of that (now).
It means "Collection of Emacs Development
Environment Tools" [1]

> People are welcome to scan MELPA packages and
> suggest to their developers to submit them to
> Emacs.

Shouldn't stuff from MELPA be moved to ELPA
first before it is moved into Emacs? :)


[1] http://cedet.sourceforge.net

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal