Re: Is Elisp really that slow?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 17 May 2019 21:24:29 +0200
> From: Ergus <spacibba@aol.com>
> Cc: help-gnu-emacs@gnu.org

This discussion is going nowhere useful.  So I'm going to respond just
to a couple of minor issues, and let's just stop and agree to disagree
about the rest, okay?  (Personally, I'm amazed you use Emacs with such
ideas in your head, excuse my being blunt.)

> >> Join similar "opposite" commands like C-o and C-j, or comment
> >> uncomment to exploit negative prefix for one of them
> >
> >This is not ergonomic for frequent commands (witness how you exempt
> >DEL from this scheme), because typing the prefix too frequently is
> >painful.
> >
> >
> >Anyway, which other editor does that?  They all have different
> >commands to DO and to un-DO.
> >
> They use C-z and C-S-z for undo-redo.

I didn't mean "undo" literally, I meant "do-SOMETHING" and
"UN-do-SOMETHING".  Every editor I've met has different commands for
action and counter-action, while you say we should have a single
command that does both.

Of course the fact that undo and redo have different keys only
confirms my point, and refutes yours.

> >> Reserve one prefix only for user specific functions and recommend
> >> the packages not to use that.
> >
> >That's C-c, which we already have.
> 
> But some modes sets commands there like message mode

This is a tangent: you said "reserve one prefix", and I pointed out
that we already did.

> >> Compilation errors and warnings are much simple to find that way.
> >
> >Our compilation-related features make that entirely unneeded.
> >
> If we use only C, yes, but in PHP (where an interpreter server produces
> a log), Python mode (that the script is sent to an external terminal) or
> Latex projects (built in latexmk), or fancy compilers like Rust... in
> general we end up opening a terminal (in or outside emacs) an building
> by hand. CMake project are difficult to set up as they use out of
> sources compilation for everything and in tramp mode the remote
> compilation usually needs to set up environment or lmod modules
> dynamically ...

That just means we need to extend our support for those other
languages.

> The compilation engine can't be optimized/configured for
> all those cases. If we do for 300 use cases there will be 300 more at
> the moment.

I disagree with this, I see no reason not to extend our support to
more languages as needed.  We are doing that constantly.

> >> Also, going to a line is the kind of command that must have only a 2
> >> keys binding by default (and probably a behavior like
> >> goto-line-preview by default)
> >
> >Why would one need to go to a line by its number, when you have
> >fast-movement commands like "C-u C-u C-n"?
> >
> This is a joke right? ;) xdisp.c is a good example: long file, long
> functions, lisp variables in the button and macros on the top.

And you go there by line numbers?  Meaning that you remember by heart
the line numbers of those places?  Me, I use M-. instead, and
occasionally M-C-s and M-> (a.k.a. C-END).  I don't really care on
which line number these variables and functions live.

> Another example is how imenu fails in C++ mode when there are classes
> and namespaces in a long file. So for going to a function isearch or
> line numbers are the only alternatives.

No, the alternative is to improve the features that fail to find what
they are supposed to.

> >That's the price, yes.  But removing valuable features to make the
> >maintenance easier is IMO the wrong way of solving this problem.
> >
> It is the only really scalable solution I can see in the medium-long
> term.

I see at least one more: make the developer team larger.  Which is
actually happening, albeit slowly.

> Unix principles imposes here, do one thing and do it right

That's not applicable to Emacs, since Emacs is not a tool, it's a
programming and text-editing environment.