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: Wed, 15 May 2019 22:46:29 +0200
User-agent: NeoMutt/20180716

On Wed, May 15, 2019 at 05:14:18PM +0200, �scar Fuentes wrote:
Dmitry Gutov <address@hidden> 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.





reply via email to

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