Re: Is Elisp really that slow?

[Ergus]

On Wed, May 15, 2019 at 05:14:18PM +0200, �scar Fuentes wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > > I think I already explained the issue, but I'll put it this way: what
> > > you would do about C-c C-c on C-Mode and how that would help their
> > > users?
> >
> > Pretty much what you suggested. Remove the binding and mention that in
> > NEWS, together with the existing alternative.
>
> You forgot to mention how removing C-c C-c would help CC-Mode users.
>
> And, as already mentioned, comment-dwim is not an alternative to
> comment-region. They do different things.
I agree that they are not the same, but I think also that users use one
or the other in their workflow, so wasting 2 short (comfortable)
bindings for the same action is not the right to do in any case. Also
short commands like M-; should be prefixes (like C-c or C-x).

In the unification process that's something that may be organized too:
if the short bindings must provide simple commands like comment-region,
or if they will provide more heuristic versions with dwim. And if the
opposite actions will be prefixed with C-u or C--

> > Some users might be upset, most won't care, and some will be educated
> > about the better alternative. The binding would also be freed for some
> > feature in the future, like C-REPL maybe.
>
> So we have certain downsides in exchange for hypothetical future
> advantages.
>
> Different modes have different requirements and it is natural that the
> same bindings do specific things on each case.

Comment region is common to all languages, and send to terminal (or
compile and execute) is common to most languages.

> Following your logic, as we have some modes where C-c C-c sends text to
> a terminal and others where it is used to indicate that the current
> edition has ended (and others where it interrupts current execution, as
> in Eshell) we should decide that the binding will do one and only one
> thing, and remove it from all other modes where that thing does not
> exists.
So... I am scared now to be sincere here... but yes. That's better (and
more logical) than confusing and scare the users. Any way the bindings
must be associated with primitive actions (most primitive and abstract
the best because they will be applicable to more possible actions in
more options) so the derived modes just need to re-implement the action
but if they rebind the primitive in their config they still will keep
uniformity.
> At the end, we deplete the available bindings from each mode just for
> the cause of coherence.
But we won't have any conflict with external packages in some modes and
not in others because the actions and the reserved bindings will be
clear..
> Doesn't look like an improvement to me.
If everything is organized in advance it will be, actually it may
simplify and reduce a lot of redundant code, reduce the manual (good for
developers and the users because will need to read less to start
working), avoid conflicts in the mailing list (and discussions like
this). Help external developers to provide better packages at leas more
organized and standard without conflicts with the internal
functionalities.