Re: Is Elisp really that slow?

[Emanuel Berg]

Ergus wrote:

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

Well, if you ever feel you get an unpleasant
answer from me, tell me immediately, thru an
off-list mail if necessary.

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

Hey, man, relax. We don't need to do anything
and we certainly must not. We need food and
clothes and shelter. If you feel that what you
mention is so important, start working on it
today! It is much more rewarding and less
frustrating that trying to convince others you
are right. But as/if you do, please do continue
to tell us all about it, of course.

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

Well, Emacs isn't consistent in that sense.
I think it never will be. I don't see a huge
advantage having it consistent either, if that
is even possible, actually I see many
disadvantages to it. If the `C-c C-c', which is
a short and close (i.e. fast and good)
shortcut, if that is always to do the same
thing, many modes that do not do that _at all_
will be one short, close, and fast shortcut,
eh, "short" (... :)). Besides, people are used
to the shortcut! Changing them to have
potential future generation of Emacs users have
a more consistent interface will just make tons
of people, who already use Emacs every second
day, unhappy.

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

Find a spot and start working, is again my
piece of advice! Start small and post on
gmane.emacs.devel and see what happens.
Keep posting here as well tho. It is much
appreciated if you ever got the impression
it isn't.

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

Not all new users are that afraid! Some think
Lisp is awesome and that is a big reason they
came to and stayed with Emacs. What one can do
with Lisp, in terms of Emacs, but also in terms
of Lisp itself, and actually even the very
language, Lisp, itself! Emacs user's
contribution to the Lisp world is huge.

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

Again, pick your favorite of the ones you
mention and start working on what you think
is lacking!

> 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

OK, let me tell you straight off without being
unpleasant, I hope, this is a complete dead end
for you. Don't go there.

Because we *want* Dired, Emacs-w3m, Gnus, ERC,
and everything else! Just as much as we want
the programming modes.

There is no contradiction. On the
... contrary :)

> What happens now is that if a user wants
> a simple editor with indentation support and
> syntax highlight for multiple languages

I'm not following? We have that.

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

IMO things that work should _never_ be deleted.
If it isn't used, like ever, perhaps move it to
ELPA. But don't delete it.

> And as a plus the Elisp language and
> interpreter, two more things to maintain
> and update.

Again, it is there because we _want_ it!

> So, in spite of our product is better [...]

Is it? The way you talk of it one would think
you wouldn't think so? But I agree, of
course :)

-- 
underground experts united
http://user.it.uu.se/~embe8573