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: Óscar Fuentes
Subject: Re: Is Elisp really that slow?
Date: Sun, 19 May 2019 20:40:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Stefan Huchler <stefan.huchler@mail.de> writes:

> I replaced as example C-c C-c in org mode (edit-special) with Menu + d +
> d, the problem is that vanilla Emacs doesn't allow that kind of bindings
> as far as I know:
>
> (:map xah-fly-e-keymap
>         ("e" . (lambda () (interactive)
>                  (if org-src-mode (org-edit-src-exit)
>                    (org-edit-special)))))
>
> But I have no standard keyboard, but the fly-keys can also be accessed
> with Space + d + d. (in command mode)
>
> And it's e in the code because I use dvorak. d is easier to hit as c,
> and C is not more rememberable then d it's completely randomly chosen.
>
> 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.

I'm afraid that this is hard to fix from Emacs. People (myself included)
tend to chord in unhealthy ways. The problem is similar to postural
injuries: you feel comfortable but you are harming yourself on the long
term. The real solution is to train people on ergonomics. Admitedly,
Emacs is not a model of good practices on this regards.

> But the main problem is not the char you use but that you have to hold
> this modifiers, which "reduces ergonomics" as compromise I would also
> be ok with having some sort of sticky keys? and you press once Ctrl
> release then press c c.

I'll argue that holding "C-c C-c" is more ergonomic that "C-c c". As for
sticky keys, maybe you can activate them with your OS/desktop
environment?

> But this is not even a optional feature in emacs:
> https://www.emacswiki.org/emacs/StickyModifiers
>
> And I would argue it should be the default behaviour, but it should at
> least be a opiton. So don't claim it has to do with mnemonics or
> ergonomics it has historic reasons not more not less. I would also argue
> that consistence is not that important.

I never claimed that C-c C-c was chosen because it is ergonomic on a
global sense, but because is ergonomic given the imposed constraints
which require the C-c prefix for major modes.

> 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...)
>
> That would give at least so much consistancy that you don't have to
> change the keybinding 50 times in 50 modes if you want to change it, and
> in some where I was to lazy yet I still have to press C-c C-c and in
> some I press my Menu + e + e. 

This is one of those ideas that sounds good when proposed but are hard
to implement. You will face obstacles as, for instance, the fact that
key bindings are mentioned on the manual files as well all over the
websphere on questions and answers, etc. Then you have the problem of
collisions, etc.

This is an area that I'm interested on and, on the past, I proposed some
steps towards better discoverability and ergonomy and volunteered to do
the boring, lengthy, clerical part of the job, but no Emacs hacker was
interested enough to do the technical part.

I also pondered similar ideas to what others proposed on this thread
about some sort of "semantic" UI but it is a very hard problem, moreover
if you try to implement something solid that could be defended with
rigorous arguments instead of something that others will view as a
collection of personal quirks.




reply via email to

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