help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is Elisp really that slow?


From: Ergus
Subject: Re: Is Elisp really that slow?
Date: Sun, 19 May 2019 15:38:19 +0200
User-agent: NeoMutt/20180716

On Fri, May 17, 2019 at 11:12:39PM +0300, Eli Zaretskii wrote:
Date: Fri, 17 May 2019 21:24:29 +0200
From: Ergus <address@hidden>
Cc: address@hidden

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]