Re: Is Elisp really that slow?

[Ergus <spacibba@aol.com>]

On Fri, May 17, 2019 at 04:13:53PM +0300, Eli Zaretskii wrote:
>
>
>Is an Emacs installation really significantly larger than a Vim
>installation nowadays?
>
In arch Linux:

39M     /var/cache/pacman/pkg/emacs-26.1-2-x86_64.pkg.tar.xz

1.5M    /var/cache/pacman/pkg/vim-8.1.1186-1-x86_64.pkg.tar.xz
5.6M    /var/cache/pacman/pkg/vim-runtime-8.1.1186-1-x86_64.pkg.tar.xz

>> The gui interface is not important at all for me. This is one of the
>> very simple changes that could take 5 minutes to do and 3 months arguing
>> in the mailing list.
>
>Then I guess you are in a minority.  Certainly among newcomers.
>
Most Linux users are very terminal lovers. Actually many mac users like
mac because there is a bash shell, and even MS added the BashOnWindows
for a reason. 
>
>
>In that case, I don't even understand why you brought that up.  Not
>having modes comes with a price, and IMO it is not too high.  Once we
>all are on the same page about this basic fact, we should stop wasting
>time discussing it.  Arguing for a change in basic bindings like C-f,
>"C-x C-f", etc. is a non-starter, the community will never agree to
>something like that.
>
I know, but still those they are uncomfortable distributed on the
keyboard. Now that the TKL keyboards are becoming popular again is not
a good idea to rely on the arrow keys too much.

>> My real proposes (if any, which is not actually) would be to change
>> those basic ones with jkli, or asdw (it is just an example).
>
>This is not going to fly, no way.
>
I know that's why the "(if any, which is not actually)" was added.

>> Delete redundant bindings like ESC = Alt for prefixes, M-4 = C-u, or
>> the numerical prefixes with alt and C and keep only one.
>
>This will cause more keystrokes in some cases.  E.g., if the binding
>is Meta-something, the M-digit binding is very handy, and the same
>with commands that are Control-something.
>
I still don't know any user that uses the numeric arguments for common
commands. But I know this won't change either.
>
>> 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. That's why I asked in other email
about case sensitive bindings. Same for many others.

>> 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, so the user needs
to care not reassign any in all the modes he uses. And sometimes there
are collapses (personal experience)

>> Enable some extra verbose features when there is not any
>> configuration file and not using -Q (because it is a hint that
>> probably it is a new user or an old user in a foreign machine) (I
>> mean which-key for example)
>
>What is which-key.
>
https://github.com/justbur/emacs-which-key

>The idea to be more verbose is an interesting one, but I don't yet see
>what kind of implementation do you envision.  For starters, where will
>the extra text come from, and where and under what conditions will it
>be displayed?
>
https://github.com/justbur/emacs-which-key
https://github.com/abo-abo/hydra

These are good starter points. Abo-abo actually holds a copyright
already. And all his packages modernize emacs a lot.

>> Actually all vim users are terminal users
>
>Then I don't think we should be too interested in those, when we
>describe modernization of Emacs.
>
I disagree, specially considering that the GNU/Linux OS is our main
destination. Else we need to center more in MSW (no coherent with free
software promotion, but also, in that case, the cua-mode must be
default, because C-x C-c C-v C-z are the standard there for
everything. And we won't convince any average MSW user to change that.
>
>
>> The gui support is a good move, but most of our potential
>> (short-medium time) users are terminal dependents.
>
>That should be backed up by some statistics.  I don't think it's true,
>but even if it is, it just is one result of us lagging behind in the
>IDE department.
>
We just need to consider the statistics of the users who use emacs
(including spacemacs) and what OS they use. Linux for desktop is sadly a
fail in the short medium time, but the number of GNU/Linux users keeps
growing (very slowly, but growing). And the most popular distributions
are not the most fancy-desktop-oriented ones. At the moment we can't
compite as an IDE for comercial software, so the probabilities that a 20
yo MS user chose emacs over VS or androidStudio are very low compared to
a Linux user that is developing backend, embedded systems or HPC. And
also the door for windows is opening with Azure and BashForLinux.
>
>> >Line numbers are a _must_ in vim, because so many commands _require_
>> >you to name the line numbers.  See your example above.  That Emacs
>> >originally didn't have line numbers is because you don't actually
>> >_need_ them so much.
>> >
>> For programming it is a must, actually.
>
>I disagree.
>
This is a deadlock ;p
>
>> 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 ... 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.
>
>> 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.

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.
>
>> >This also means that you can never have a MUA in vim, or an IDE, or a
>> >debugger front-end or anything even remotely similar to Org.  Let the
>> >people who want simplicity at a price of a limited editor use vim.  It
>> >is not them that I think we should attract.
>> >
>> I mention this because there is too much code to maintain and of course
>> we can't do the best in all those fields.
>
>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. And it is not applicable to everything of course.

But maintain everything, add new complex features to compete with
specialized applications already available that has been corrected and
upgraded among years I don't think will never work (Unix principles
imposes here, do one thing and do it right). We will not create a better
Lisp compiler that specialized projects that center all their effort on
that. Or gtags or a shell. It is impossible and unneeded.
>
>> >We don't _want_ success of the vim type.  That's the wrong type of
>> >success for Emacs.
>> >
>> Why?
>
>Because we are a different kind of beast, see above.
>