Re: Is Elisp really that slow?

[Ergus <spacibba@aol.com>]

On Fri, May 17, 2019 at 06:29:44PM +0200, Stefan Huchler wrote:
>Hello guys,
>
>Eli Zaretskii <eliz@gnu.org> writes:
>
>> If you want to argue that Emacs should be a dual-mode editor like the
>> vi family, and that this is your "future", then we will never agree.
>> One of the revolutions that Emacs brought to text editing was its lack
>> of modality, where you just type text to have it inserted.  Dual-mode
>> editors are a thing of the past in my eyes, a remnant from the old
>> days when editors didn't have the real-time display, where you needed
>> to have commands like "move N lines from the current one, then delete
>> M lines" etc.  Please don't even get me (and others) started on this
>> "feature".
>
>I was reading your conversation and was mostly on your side till here. I
>have to disagree with you at this point, sure many of this do things 10
>times commands are very seldom useful, not never but seldom.
>
>But that has nothing to do with modal vs non modal. Modal is more
>efficiant, something simple as copy / paste is not only less keys to
>press but literally more healthy, pressing c + reposition + v instead of
>M-k + reposition + C-Y is just better for your fingers.
>
>And for programmers 50% of commands you do as programmer are not basic
>text manipulation like insert/delete key. So 50% of the
>keystrokes/combitations you use on emacs are a attack on your health,
>and are more likely to result in a error, hitting a long C-c C-q or even
>longer commands is not so easy, even you don't get pain in your fingers.
>
>Btw it's not only pain where many emacs famous hackers became problems
>with, it's also getting faster tired.
>
>http://ergoemacs.org/emacs/command-frequency.html
>
>But I have to admit that I use the paredit commands or at least some of
>em not so much for navigation but for manipulation. It kind of makes
>sense and they are mostly 1-2 modifier and a arrow key. They are easy to
>remember and that is a plus of course, I just think that the GNU project
>should prioratise the health of their Users more than the
>rememberability.
>
>Btw there is a middle ground, look at xah-fly-keys, besides the modal
>mode it also has a mode that depending on the keyboard can use key
>combinations that are no keychords, so you don't have to hold a
>modifier, which is what hurts your pinky.
>
>So I hit my easy accessable Menu key and then afterwards the c key for
>copying as example, the holding of keys and then stretching to other
>keys is what hurts the pinky so much and why C-c C-f as example is a
>horrible command.
>
>Sadly we have to accept the current default keyboard layout therefor the
>default settings in xah-fly keys is that space is the command key and
>that only in command mode so for that you need the modal mode.
>
>But we should not forget that the old emacs defaults were made for more
>ergonomic keyboards that today we don't have anymore:
>
>http://ergoemacs.org/emacs/emacs_kb_shortcuts_pain.html
>
>They had the Ctrl and meta/alt key switched. So witch a bit of flexing
>you could press the ctrl key with your thumb and not with your pinky.
>
>So that the keyboard shortcuts are optimised for A rememberability and B
>old lisps keyboards that 99.999% of the users don't use is surely not a
>good default, I am sorry.
>
I have experienced the issue that when adding a new functionality (to
isearch) there is not an available/standard method to assign a binding
for it. But also I ended discovering a new set of shortcuts I didn't
know. 

>A way to solve that would maybe be intergrating something like ergoemacs
>or xah-fly-keys and if you start emacs without config ask do you want
>modal or classic mode, or something along that line.
>
That could be something very interesting.

I am not proposing to make all the ergoemacs changes, but there are
interesting ideas there.

But ergoemacs actually failed because all the modules and packages bind
the default keys to the "expected" action. So for example next-line is
hardcoded to anything that moves one line down in helm, counsel, emms,
and so on. So at the end the user never gets a real 100% ergoemacs
experience. Similar happens in evil mode or even in cua-mode that is
integrated inside emacs. One never gets the 100% of the experience.

>Heck switching Control and Meta key in all keyboard configurations would
>probably better the situation a lot. Because that was what the first
>developer wanted back then with their lisp keyboards, but because of
>backward compatibility the sitution became worse because the keyboard
>changed and no emacs developer reacted to it.
>
>> And you contradict yourself here: simple text editors all provide
>> operations on the selected portion of text.  Emacs does that, while
>> vim tells the users to remember the cryptic "N,M s/foo/bar/g" stuff
>> that goes back to the 50-year old ed(1) and sed(1) editors!
>
>I agree on that
>
>> Excuse me, but this is nonsense.  Our menu and tool bar say copy/paste
>> for at least 20 years, as do the manuals.  I wonder when people will
>> stop beating this dead horse.
>
>Yet how do you remember M-k and C-y because you know it means kill/yank,
>else this shortcut makes no sense, so at least if you prioratise
>rememberability over the health of the developers be consequent, if you
>call it copy and paste make it C-c or M-c and for paste C-p. Then you
>would at least be consequent.
>
>That C-p is bound to previous line is no real reason because you also
>have they arrow keys bound to it (which also is easier to remember), and
>that C-c is for extentions their shortcut beginning also don't matter
>because that problem is solved in cua-mode just add a small timer if you
>are not fast enough to add the second part it's copy if you are fast
>enough you can do your long shortcut.
>
Personally I won't like to use the arrow keys, but if that could release
some bindings for a more standard behavior and simplify the access to
some functionalities (like get indentation), I will respect the
decision.

Another opportunity to release and access some similar commands affected
by the lack of bindings is to unify isearch with replace as isearch-mode
already have its own map. for a dynamic behavior there is the iedit
package. and multi-cursors.

swiper actually uses C-s for search, but C-n and C-p for next and
previous candidate, and with a bind to C-c m enables multiple cursors
(to replace all) and as C-r will be free, then it could be used to
switch from isearch to query-replace (as M-r switches to regex search).

Please, don't tell me that this won't fly; I already know.