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: Fri, 17 May 2019 19:19:17 +0200
User-agent: NeoMutt/20180716

On Fri, May 17, 2019 at 06:29:44PM +0200, Stefan Huchler wrote:
Hello guys,

Eli Zaretskii <address@hidden> 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.



reply via email to

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