Re: Is Elisp really that slow?

[Ergus <spacibba@aol.com>]

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