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: Emanuel Berg
Subject: Re: Is Elisp really that slow?
Date: Thu, 06 Jun 2019 02:16:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Stefan Huchler wrote:

> But another suggestion for that, if C-c C-c
> is meant as shortcut for
> a "important-function" why not have a binding
> for "do-important-action" or
> "do-major-action" and depending on mode that
> functions calls the important function of the
> mode. So that the user can choose globaly
> a keybinding for that and don't has to do
> that for 80 modes seperately. and the
> developer of the mode just somewhere sets
> which function is bound to C-c C-c by
> setting: (setq mode-important-function
> 'compile...)

Well, there are many functions that could be
considered the important one. People will have
different ideas what is the one to use.
Instead of configuring keys, people will start
configuring what function is the
"important-function".

Besides, most people don't use 80 modes. And if
those who do are really unhappy with keystrokes
in all 80, so be it. It is easy to change the
keys for one mode, and once one has mastered
that black art, to do it for the next 79 should
be a snap. Also, one doesn't have to do it all
in one evening.

Rather, make one adjustment every day and ten
years later you still have interesting things
to do :)

> Also I would argue that most people press C-c
> C-c with left control instead of the
> ergonomic way to use the right control
> therefor you train people to use
> unergonomic keychords.

? ... why is the right control more ergonomic?
It is farther away so at least on my keyboard
I have to move my entire right hand out of
typing position to reach it, which with the
right hand fingers just get slightly of their
asdf marks.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal




reply via email to

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