Re: Is Elisp really that slow?

[조성빈]

> 2019. 5. 19. 오후 10:00, Ergus <spacibba@aol.com> 작성:
> 
> On Sun, May 19, 2019 at 07:35:58PM +0900, 조성빈 wrote:
>> 
>> 2019. 5. 19. 오후 5:16, Van L <van@scratch.space> 작성:
>> 
>>> Emanuel Berg writes:
>>> 
>>>> Ergus wrote:
>>>> I don't consider myself an Emacs expert -
>>>> far from it. But I've been here for 10+
>>>> years, so I'm happy with my Emacs and my
>>>> skill level.  But this place still
>>>> doesn't feel like home!  That is strange.
>>> 
>>> Is it possible to have the best of all possible
>>> worlds?
>>> 
>>> For conservatives, a winter release of old gold keybindings.
>>> For the free radicals, a spring release with modernizations.
>> 
>> What if having a compatibility-mode that can be activated by something like:
>> ```elisp
>> (classic-keybindings-mode 1)
>> ```
>> and refine the default keybindings to be more consistent/mnemonic? People 
>> who miss the old keybindings will be elisp-proficient; Adding 1 s-exp to the 
>> init file won’t be a barrier.
>> For the refined keybindings, Spacemacs can provide a good starting point.
>> 
> This is interesting. (of course spacemacs not in evil mode).

Yeah, of course evil’s keybindings can’t be a starting point; I was saying that 
spacemacs classify most keybindings in a pretty consistent way; we can be 
inspired by that.

> I will just tell an idea I had (before knowing how things work in emacs,
> I actually thought it was implemented in that way)
> 
> If we create a single file with the full list of general bindings as
> variables for all the main modes like
> 
> ;; Basics
> 
> C-a begin-line-binding
> C-e end-line-binding C-b go-backward-line-binding C-d delete-forward-binding
> ...
> 
> ;; Prog mode
> C-c C-c whatever-you-decide-binding
> 
> ;; Minibuffer mode
> bla bla bla
> ...
> 
> And so on.
> 
> All the derived modes can be changed to use the variables instead of
> hard-code the bindings in multiple files.
> 
> this:
> (define-key c-mode-base-map "\C-d" 'c-delete-forward)
> will be:
> (define-key c-mode-base-map delete-forward-binding 'c-delete-forward)
> 
> This is similar to use remap, but with some advantages:
> 
> 1) The bindings will be organized in a single file and the collisions
> will be exposed easily. And fixed for all of them.
> 
> 2) In case a mode adds a new functionality and it needs a binding, it t
> in the global map, it will be clear if some others already have a
> similar one and will bind to the same using the same criteria. If the
> binding has never been used, it will be added to the list for future
> modes that wants the same functionality.
> 
> 3) Old users will be minimally affected because the starting criteria
> are the actual bindings.
> 
> 4) Implementation of test modes (like ergoemacs or evil-mode) and future
> modifications will require less effort and the final experience will be
> less hacky than now..
> 
> 5) If a user personalize a binding (changing the value of one of these
> variables) the changes will apply to all the packages and modes she
> uses in his section.
> 
> 6) If the user wants to use remap or hard-code the binding (as now) the
> actual behavior will be unchanged.
> 
> 7) Packages like elpy, irony, or company will also use the "binding-list",
> so the user will only learn the most specific bindings (if any) so
> external packages will be standardized with minimal effort.
> 
> 8) Future bindings changes that the community agree will not require
> changes in the files of all the modes. With the potential side effects.

This, at least for me, feels like a fantastic idea :-)
IMHO the point of this is that we can now have a list of functions that are 
common between modes; which will help users having a coherent experience and 
provides package authors a minimum start point to provide a pretty-good 
experience.

> I know that proposing this here is a crazy idea, but the intention is
> not to start a crazy war again, If it is crazy (for technical reasons)
> just ignore it. Actually I just mention it because it seems to me like
> something extremely simple-advantageous and maintainable. With minimal
> affections to the user space.
> 
> But remember that we have a limited number of bindings so managing them
> better is important if we want to find place for new functionalities.
> 
> In any case I will leave this threads as it is not going anywhere (as
> usual with this topics) and what is obvious for me seems to be heretic
> for the rest. But you are free to consider the idea if it has anything
> useful for emacs..
> 
> 
>> 
>>> When I use a long M-x sequence, a shortcut suggestion appears. It 
>>> disappears before I can catch it. Can it stay for 30 seconds? Can there be 
>>> an instant interactive override to set it whatever you like?
>> 
>> I would like a semi-AI that suggests interactive functions based on key 
>> presses or actions the user performs... `You can use C-e (goto-end-line) to 
>> perform 12 keystokes you performed.'
>> Saying about discoverability, I would like a context-sensitive right-click 
>> mouse menu, something like Microsoft Office. Most newcomers are familiar 
>> with finding functionality with the mouse; and it isn’t intuitive to find 
>> new keybindings/functions that Emacs provide to boost productivity. 
>> (Actually, that’s one of my problems; how should I find new functions...?)
>> 
>>> Evolutionary programming of popular custom keybindings collected at 
>>> upstream and put thru obstacle course competition is one way of composing a 
>>> spring release.
>>> 
>>> --
>>> © 2019 Van L
>>> gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
>>>                            "The interface is a nightmare." - Brendan Schaub