Re: Is Elisp really that slow?

[Ergus]

On Fri, May 17, 2019 at 11:12:39PM +0300, Eli Zaretskii wrote:
> > 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.
Actually my proposal in this point was just to find a way to release
some bindings. It was not even a real proposal at all, just an attempt.

What is clear is that all the bindings are set and we talk about new
features without binding (or a plan to bind them). Y made all the
possible questions, case sensitive bindings, release some of them, make
a C-a go to indent and then to beginning of line... anything to have
some more place without create longer bindings.

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

So why C-mode, message modes and others bind commands there. Then the
user does not have a reserved place confident to no create collisions. 


> > >> 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.
That's the perfect choice (utopic), with the actual number of
maintainers, ignoring whats already in melpa (that is a lot of community
work and time improving) I think I am pessimist about the
materialization.
> > 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.
The new methods standards and systems complexity grows faster and in
many directions that what we can maintain updated enough in the core. It
is not a theoretical problem, it is a practical limitation.  
> > >> 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.
OK, different workflows. 

> > 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 true, but in the mean time that's what we have and some bugs need
years to be solved. This in fact is a consequence of the C++ support
limitations we were mentioning before in this threads. 
> > >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.