Faster, more robust, less featured version
wlandry opened this issue · 81 comments
I have a branch of ergoemacs at
https://github.com/wlandry/ergoemacs-mode
that fixes a number of problems I was having with specdl, timeouts, and generally slow startup. It was bad enough that mu4e was constantly breaking. These fixes make it usable for everyday use, and I have been using it for several months without problems.
The catch is that I have radically simplified the scope of ergoemacs. It no longer supports fly-keys, cua, gradual ergoemacs, and probably some other things I do not remember. So I do not know if you are interested in merging these changes, but I figured that I should ask.
I have been thinking about simplifying by pre-compiling something like you have based on layout and gradual adoptions. The fly-keys going away is fine with me, cua seems necessary but likely could be added with cua-mode. The thing that I am assuming you may not support is the different keyboard layouts.
I use Colemak exclusively, so I definitely support alternate keyboard layouts. Please let me know if you see any problems!
The cua support that was built into ergoemacs depended on timers to get everything to work, but that makes everything very finicky. Also, C-c
and C-x
are very common prefixes used by other modes (e.g. C-x C-f
and C-x C-s
). I really did not like that if I paused while typing a key sequence, I would get a different result. It tends to break too many things. In general, I think of ergoemacs as bindings for Alt, not Ctrl. Cut/Copy/Paste are M-x
/M-c
/M-v
.
In any event, just now I tried enabling cua-mode in a small file. I could copy with C-c
and paste that content with C-v
, but not with M-v
. Looking up the key-binding for C-c
(C-h k C-c
) did not work. So it is not entirely seamless.
I also got rid of gradual adoption. It feels that changing some of the keys but not others leads to weird conflicts, especially with alternate layouts. I think of ergoemacs as an alternative like vi-keys, using the Alt key to indicate a different mode. So you kind of have to commit to it.
One thing that I forgot to mention is that I got rid of the Apps/Menu bindings. I do not have those keys on my keyboard. So I guess it is more like Level 3?
I do use the menu keys, though I am not sure if I am the only one. I personally use the reduction key theme; Did you take away the themes? Just curious from my end.
I also use exclusively colemak (not colemak-dhk, vanilla colemak)
Also, I looked up key bindings from the global keymap and then bound them with a new minor mode or major mode. Did you make a way to add these easily from your end? It would make supporting minor modes easier.
Also removing ergoemacs-mode removes the arrow key support in the terminal mode, though I don't know if it actually works any longer. The M-o keycode is the prefix for the terminal arrow keys.
I wouldn't mind trying it out if it supports the themes that I use. If it is easier to discuss in a meeting, let me know.
I also use the menu key to allow me to type menu t to access all the C-c without using the control chords. I personally find it very comfortable.
I took away all of the themes. My version more or less only defines global key bindings. The regular version is constantly installing and uninstalling keymaps, which makes it slow and hard to understand what was bound when.
My version fully supports the terminal. That did take some effort. You can see it in ergoemacs-handle-M-O
in ergoemacs-themes.el
.
By the way, the tests that you had set up were invaluable for getting everything working. Thanks!
Most of the minor mode support is at the end of ergoemacs-themes.el
. They are just ordinary bindings for a few modes: org-mode
, eshell-mode
, etc. However, some of it is hard coded in ergoemacs-functions.el
. For example, it handles the mapping of ergoemacs-paste
to the appropriate paste functions in term-mode
and calc-mode
. So some support for new modes should easy, but deep integration might require hacking the code. But I think that is also true for the regular version?
I removed much of the helm, ivy and icicle support. I do not use them, so I did not have a good way of testing whether they worked. I am not opposed to making them work.
Looking at the wikipedia page for the menu
key, it looks like it was originally for opening a menu without using the mouse. This seems like not a bad idea, so I am wary of rebinding the menu
key. I do not see a binding for menu-t
in the regular version. I do not know how you enabled that binding, so I do not know if my version will break it.
I altered the drop-down menu items. I do not think I did anything too radical there, but I am unsure.
I do not change Ctrl bindings for different layouts. For example, C-n
is not remapped to C-k
in Colemak. So the idea is that Ctrl bindings are mnemonics, while the Alt bindings are ergonomic. Also, I do not override Ctrl bindings in minor modes, while I do override Alt bindings. I think this helps avoid problems with other modes, since they tend to use Ctrl more than Alt.
There is still a lot of dead code that I have not cleaned up yet.
They were using the apps layer and were defined by
"<apps> d" ("C-x" :ctl-to-alt)
"<apps> f" ("C-c" :unchorded-ctl)
You can get these keys by:
(ergoemacs-command-loop "C-c" :unchorded-ctl)
It seems like this should be valuable, but I haven't tried it since I would have to rework it to my bindings. It seems it could be that the themes could be supported by alternate code for binding different keys.
I haven't had time to look at the code yet
I looked at it and ti liked the structure and speed. It should be easier to maintain in the long run.
At the same time, as I mentioned, I still want ergoemacs-command-loop
to save my pinky from all the Control combinations of C-c
even if it isn't bound to the menu key that we discussed.
The command loop should work without causing any problems to the keys, but it doesn't need to be called like it used to be called.
Also the way you setup keys is clever enough to add back some of the gradual ergoemacs-mode themes and also at least my theme.
Do you think that these things make sense to you?
If so, maybe we can merge your changes to a branch and work through these ideas together. What do you think?
I personally am in favor of dropping modal, fly keys, and making menu keys highly optional. I still agree with Xah's point of view of the menu key as a leader, though this could be a personal preference thing to me.
The mode is now just plain key bindings. I deliberately removed as
much of the ergoemacs-command-loop
code as possible because it was
the source of many problems.
If you want to bind the menu
key to C-c
, I think this accomplishes
that
(define-key key-translation-map (kbd "<menu>") (kbd "C-c"))
Will that work?
In general, I am happy to make it so that this does not break for you.
But at least on Linux, menu
is mapped to execute-extended-command
aka M-x
. Since I do not have a menu key, I am hesitant to decide
whether it should be C-c
or M-x
or a more generic leader key.
Also, I do not like the idea of optional bindings. It makes it hard
for me to understand how the mode works with different options. Some
problems you can only see if you use it a lot. So I am not all that
keen on supporting the gradual ergoemacs themes.
Also not sure if the following keys are handled in the gui vs terminal:
C-i, C-m, and C-[
I just manually tested it, and it seems to work.
Will that work?
No. That will not work.
In colemak
<menu> s o o
would be equivalent to C-c C-o C-o
My point is to remove the control key usage and chords since that is one of the large sources of RSI pain. Also many other people have spoken to me about how the menu key made many key bindings easier to reach.
I do understand that the commnad loop was a source of many of the problems you seen. But I think we can have a version that is basically key bindings except when it enters these read-key types of scenarios.
I have already changed the code so I can use the reduction theme. The issue for me is bringing back the functionality described above.
https://github.com/mattfidler/ergoemacs-mode
has started this and still should work around all the problems you seen.
Also in the current ergoemacs mode
<f2>
is the edit that was used in multiple places (You usedC-c C-q
)- You didn't include the isearch to replace in the isearch mode map.
As far as gradual ergoemacs themes, I am also OK not supporting them.
I think I understand a little better. Mapping menu s o o
to C-c C-o C-o
is a very different kind of keybinding than what I am thinking. I do not doubt that it is useful for you, but it seems orthogonal to the rest of the keybindings. Especially since I can not test it on my keyboard. I want this keybinding to be complete without the need for extra keys. I am happy to avoid binding anything to the menu
key so that you can layer the mapping on top. Since my bindings are just simple bindings, you should be able to do whatever magic you want to get menu
working.
However, I do not want to include competing keybindings. For example, what do M-h
and M-H
do? In my version, they run move-beginning-of-line
and move-end-of-line
. In your reduction theme, M-h
runs isearch-forward
and M-H
is unbound. Instead, you bind M-m
to ergoemacs-beginning-of-line-or-what
and M-.
to ergoemacs-end-of-line-or-what
. But that conflicts with the default binding of M-.
to xref-find-definitions
, which I use ALL THE TIME. We should just figure out what all the bindings for the Meta keys are.
I am confused by the comment about <f2>
and C-c C-q
. Do you mean C-x C-q
? Another principle I followed was to avoid binding anything to the <fn>
keys. I want to keep those free for users to bind.
For implementing isearch to replace inside isearch, are you saying that I should bind M-5
to isearch-query-replace
in isearch-mode-map
? I am happy to do that.
First of thank you for all your work. I think the overall work that you did is excellent. I will go point by point and respond from my perspective.
Orthogonal key bindings
I think I understand a little better. Mapping menu s o o to C-c C-o C-o is a very different kind of keybinding than what I am thinking. I do not doubt that it is useful for you, but it seems orthogonal to the rest of the keybindings. Especially since I can not test it on my keyboard. I want this keybinding to be complete without the need for extra keys. I am happy to avoid binding anything to the menu key so that you can layer the mapping on top. Since my bindings are just simple bindings, you should be able to do whatever magic you want to get menu working.
I can see how you would think that this use case is orthogonal from the keybindings in general.
So, maybe I should reflect on the purposes that I had in mind when Xah and I created the keybinbings; They are as follows:
- Reduce the causes of RSI and be in general an ergonomic keybinding
- To allow easing into emacs by supporting the commonly used key shortcuts
- From my end, to not harm other's keybindings
- Follow Xah's ideas about menus and how keys should be represented so that newer people can be introduced to emacs easier.
To put my perspective on these keys, I will talk about the first and third point here.
Reduce causes of RSI
I am sure by know you know the causes of the so called emacs pinky -- control combinations that contort your hands. The first step that Xah made was to use the thumbs/alt to allow less frequent usage of these combinations, which is the keymaps that he used at the time.
As blogged about by Xah, the shift key is also problematic in causing RSI, so the reduction
is a further exploration of this theme by reducing the shitf keys or the M-S-
combinations. Therefore, it is superior in ergonomics. When I created it over 5 years ago, I thought about making it the default ergoemcs-mode theme because of reduction of key chords that would reduce the probability of RSI. This was accomplished by mutli-function keys reminiscent of QMK's tap-dance feature.
Of course, getting rid of the control combinations completely in emacs is aligned with this goal and made it into the reduction theme (these apps d types of keys). Therefore, to me instead of being orthogonal to the keys, it was essential to the key combinations. In theory, this sort of approach would reduce any emacs user's RSI, though like the rest of the items it takes commitment to try.
Also of note, what is ergonomic for me may not work for you. This was the original reason for the themes.
Do no harm to users' keys
This was the motivating factor for me keeping the old keybindings the default keys. For me, it was super frustrating to be an earlier adopter of Xah's keys and to have them change without some sort of note. The other problem for me was that the advertised keys did not match for my colemak layout (instead of his dvoarak layout). The ergoemacs key binding was born of this. The looking up the key and inferring what a mode means was also caused by that idea.
The ergoemacs command loop was interlaced with looking up key binding lookup which caused issues with both.
In this simplified version you separated out the key binding lookup and used standard keys. This was the prior approach, though it didn't use the custom layout translation.
Unfortunately your new code broke some of my key bindings and not just the ones discussed above (multiple cursors broke, and likely other breaking would occur with company mode, auto complete mode, helm etc etc). This is likely to affect others' keybindings as well.
This generalized key-lookup solution caused speed issues and problems with some modes. So it isn't ideal, as I said in the past. However in terms of correcting more keymaps it is more robust than the simplified approach.
Still I want to do no harm. Since emacs users are quite astute, a simple function to lookup the key-binding changes for a specified key map would probably be the best way to support these issues. If it is a common enough routine, these should be possibly added to the main library, like it was done in the past.
However, I do not want to include competing keybindings
I agree with you in the terms of maintainability, it is difficult to include both.
From my perspective if we choose only one it should be the reduction
theme because it is more ergonomic than the standard ergoemacs theme. However, the regular ergoemacs mode has been around for so long I am a bit hesitant to change them. I know there are other reduction users out there, so removing it would make one group of users unhappy while removing the standard errgoemacs would make antoher group of users unhappy.
The best solution I have is to split the effort and you would support the standard ergoemacs keys and I could support the reduction ergoemacs keys.
<f2>
I can see your point of view about maintaining a group of keys that are user defined.
At the same time, this was not done when we created the key-bindings. The F2 was bound to edit and F11 to full screen. There were other keys bound like F8. I worry about taking these away, but I think it is a fair statement. To me, these can be easily added back by the user.
The F keys allow a movement and rest for the hand, so at the time they were considered ergonomic.
I am OK with removing the f2 for edit, but I think from the ergonomics principles I cannot pass the red face test when binding it to something like C-x C-q
(sorry, I thought it was C-c C-q
, even though it is the emacs way...
For implementing isearch to replace inside isearch
Yes it should be implemented.
My main point is that this should be done programmatically to make sure we are not missing other keys. I am definitely not saying this should be done on the fly anymore, but rather to some user buffer that can be adapted to any misbehaving mode.
Also, have you signed the gnu FSF contract? That is needed to get this to elpa.
As a note, to align with the original principles of ergoemacs-mode the following will need to be added back:
- cua keys, though we can use cua-mode and/or instruct the user to use that
- Use the more common key names for the keystrokes. This can be disabled (and always could be)
Also, have you signed the gnu FSF contract? That is needed to get this to elpa.
No. I suppose I could, though I thought that required talking to my
employer? I could probably get my current employer to do that.
However, I am changing jobs, and I know nothing about whether the new
employer would sign off on it.
As a note, to align with the original principles of ergoemacs-mode
This might be where we are running into difficulties. I am not really
on board with all of the original principles of erogemacs-mode. As
one example, I do not think it is important to make cua keys work.
You just wrote a long message about how terrible the C-
bindings
are, and I partly agree with you. To that end, if anything, I want to
get rid of the remaining C-v
and C-z
bindings.
The remaining C-
bindings are not too bad for me on my colemak
keyboard. You gave the example of C-c C-o C-o
, but I have never
used that binding. I use C-o
and C-s
regularly, C-c C-c
occasionally, and C-S-n
and C-x C-q
maybe once a day. Those last
two are problematic, but I use them infrequently and I do not have a
good replacement. I consider the fn
keys off limits.
Also, I need a layout that is good for laptop keyboards. Laptops do
not generally have the menu or apps keys, so I do not want to put any
functionality there.
Do no harm to users' keys
One of the key reasons that I went to a model where I provide simple
bindings with some specializations for other modes is because I found
it much easier to fix problems. Mu4e broke for me in weird ways, and
I had no idea how to fix it. So while I am very interested in any
problems you find with other minor modes, I think it is pretty
straightforward to fix these problems as I encounter them. I am
definitely not interested in adding back a command loop.
From my perspective if we choose only one it should be the reduction
theme because it is more ergonomic than the standard ergoemacs theme.
I do not share your views on the Shift key, and I even think that
Meta + Shift is fine. If you get rid of all of the chorded keys, then
you end up with Xah's fly keys or vi. That is not where I want to go.
For implementing isearch to replace inside isearch
My main point is that this should be done programmatically to make sure we are not missing other keys
For this case, it should be as simple as adding
(ergoemacs-define-key isearch-mode-map (kbd "M-5") 'isearch-query-replace)
to ergoemacs-set-search
in ergoemacs-themes.el
. I do not want to
do anything more complicated than that. Trying to do everything
programmatically has caused weird, difficult to debug problems.
Do you need to have your employer sign off on the FSF agreement
I think you only have do to this if you work on this with company time.
Summary of things that I think we agree on
- The command loop should be retired for general usage
- The bindings should reduce to simple keybindings that are applied. Note the current approach requires an emacs restart without ergoemacs mode enabled. Before this was not the case.
Summary of things that may need some clarification
- My branch does not use the command loop with the exception of the unchorded
C-c
. - Note it seems like the command loop has been brought back because of the echoing of the commands that are currently typed in the
ergoemacs-mode
way. That can be turned off as a user-enabled option. - To ease support for minor modes, a function that creates the lisp code for the bindings on mis-behaving would be helpful. NOTE this only creates the lisp code but does not do this on the fly and is easy to debug since you control adding the keys. In fact, we could tell people to simply run the code and whatever key changes they have applied could be applied to their keymaps. This way both problems could be solved.
Things where we disagree
- The main aims of
ergoemacs-mode
. I don't think these should change the original tenants for general usage. However the things you mention should be able to be changes from a user perspective, as I stated ergonmics is individual and emacs configuration is individual as well. - Dropping shift as much as possible. I originally thought the same as you, but dropping it actually reduced my hand strain. I agree that you don't want to change your keybindings. I am sure you can understand that I do not want to change my keybindings either. The best work-around from my perspective is to support both standard ergoemacs mode as well as the reduction mode
I think the areas of disagreements are small and should be workable. Hopefully you agree.
I will have to reach out to Stephan Monnier to start the process of the contract. Otherwise, I could reach out to him to remove ergoemacs-mode from elpa.
Note, I created a draft lookup for isearch-mode-map
and here are the keys from reduction:
(ergoemacs-define-key isearch-mode-map (kbd "C-M-:") ’isearch-occur)
(ergoemacs-define-key isearch-mode-map (kbd "M-d") ’isearch-delete-char)
(ergoemacs-define-key isearch-mode-map (kbd "M-v") ’isearch-yank-kill)
(ergoemacs-define-key isearch-mode-map (kbd "M-V") ’isearch-yank-pop)
(ergoemacs-define-key isearch-mode-map (kbd "M-5") ’isearch-query-replace)
(ergoemacs-define-key isearch-mode-map (kbd "M-h") ’isearch-repeat-forward)
(ergoemacs-define-key isearch-mode-map (kbd "C-M-d") ’isearch-repeat-forward)
(ergoemacs-define-key isearch-mode-map (kbd "M-y") ’isearch-repeat-backward)
(ergoemacs-define-key isearch-mode-map (kbd "C-M-s") ’isearch-repeat-backward)
(ergoemacs-define-key isearch-mode-map (kbd "M-t") ’isearch-complete)
I think the couple that nay need to be added are yank-pop
isearch-complete
, and isearch-query-replace
Thank you for this. It is fast and responsive.
After sleeping on it, I will be removing the F# key bindings. Most of the commands are too personal to be something of general usage. I will also review some of the menu keys and probably be removing some of them.
However, I will start from this branch anymore for the following reasons:
- Most importantly, I do not wish to jeopardize your job in any way. I don't want the FSF agreement to get in the way of your employment. With these uncertain times employment is very handy.
- This doesn't respect user-defined keybindings by either binding them to the global map or the ergoemacs-override map. This was a very common complaint of earlier versions of ergoemacs and ti do not wish to bring back the bug. To bring back the feature would be more effort then removing the problem areas of ergoemacs-mode (to I say now, but I may change my mind again when I get into the weeds).
- Turning off ergoemacs-mode doesn't restore the emacs key bindings, which I think is essential to be on the emacs elpa.
- This doesn't include the edits by Stephan Monnier to keep it in elpa.
That being said, I am also inspired by your branch to:
- Remove the automapic key lookup for
ergoemacs-mode
and the corresponding injection into certain minor modes - Removing the ergoemacs-theme compoment infrastructure to create binding altogether.
Thank you again for you help and your interest
However, I will start from this branch anymore for the following reasons:
- Most importantly, I do not wish to jeopardize your job in any way.
I don't want the FSF agreement to get in the way of your
employment. With these uncertain times employment is very handy.
Just to be clear, I am sure that just asking about it with my current
employer will not cause any problems for me. I am also somewhat
confident that they would agree. That covers everything I have done
so far.
For future work, I am sure that I can ask. I have done this sort of
thing before, and I know how to ask without causing trouble. But they
may say no.
- This doesn't respect user-defined keybindings by either binding
them to the global map or the ergoemacs-override map. This was a
very common complaint of earlier versions of ergoemacs and ti do
not wish to bring back the bug. To bring back the feature would
be more effort then removing the problem areas of ergoemacs-mode
(to I say now, but I may change my mind again when I get into the
weeds).
I am a bit confused. In the global map, I unset a large number of
keys (e.g. C-x C-f
) and set a few others (e.g. C-f
). For
everything else, I set keys in ergoemacs-override-keymap
. You can
see that in ergoemacs-install-standard-theme
in
ergoemacs-themes.el
. But it is possible that something else is
causing problems.
- Turning off ergoemacs-mode doesn't restore the emacs key bindings,
which I think is essential to be on the emacs elpa.
Yes, that was something that I felt was going to be way too much
effort to make it work and keep working. Given that ergoemacs is a
total conversion, I did not think it is worthwhile to make enabling
ergoemacs reversible.
In any event, thank you for your work on Ergoemacs. I will make sure to keep an eye on it.
I am a bit confused. In the global map, I unset a large number of keys (e.g. C-x C-f) and set a few others (e.g. C-f). For everything else, I set keys in ergoemacs-override-keymap. You can see that in ergoemacs-install-standard-theme in ergoemacs-themes.el. But it is possible that something else iscausing problems.
I set the keybindings in ergoemacs-override-keymap
and it didn't do anything. I set it on the global map and it didn't do anything either. The global map was masked by the ergoemacs-override-keymap
and for some reason the value of the ergoemacs-override-keymap
does not match the value in the emulation maps. You can try out my configuration with your excellent modifications here:
https://github.com/mattfidler/emacs-config
This doesn't respect the key changes.
I looked at your emacs config. It does not bind any keys directly, and it uses a number of packages that I am unfamiliar with. Can you give me an example of a single key binding that does not work? Thanks.
It was an oversight on my part. I used ergomacs define key but forgot to use qwerty.
While the last ergoemacs mode respected global bindings this one doesnt need to.
So... Im working on the branch you started again (linked above). I think it should be possible to turn off ergoemacs cleanly. I will also remove some of the extra stuff.
It seems to work. I have stripped out more than you have. It restores the isearch-mode-map
when turning off ergoemacs-mode
.
I think it would work with the old problematic modes.
If you could check the most problematic mode, I would appreciate it.
Thank you for the pull request
Merged the changes with the master. I will reach out to Stephan Monnier to see if he can send you the contract.
I forgot to tag you @wlandry
I just tried out the terminal (M-x term
) with your new version. If I select something and copy it with M-c
, I can not paste it with M-v
. Also, C-d
does not work. It should exit the terminal.
Well @wlandry , term-mode
is a special case...
The terminal is supposed to remove all emacs/ergemacs keys. f14b71e removes ergoemacs-mode
standard keys but it doesn't provide an alternative.
With that removal, C-d
exits the terminal.
I am not sure what the keys should be, though there could be a specific map for term-mode
with some sort of prefix key, like what emacs
does, but it should probably build on what is done in ergoemacs
in some way
That is true. I forgot that I added term-paste
in ergoemacs-paste
. That will probably break things if you do crazy things like run emacs inside a terminal inside emacs. I find that binding of term-paste
to be extremely useful, but I could live with it being a local binding.
M-x calc
does not work for me. I get the error
Error running timer ‘ergoemacs-command-loop--timer’: (void-variable comint-mode-map)
It works for me... But I required comit to see if it fixes your problem
Now I can start calc, but trying to paste something in with M-v
gives the error
No known previous replacement
Trying to paste with C-v
gives the error
cua-paste: Cannot paste into a read-only buffer
Seems to be a cua-mode
interaction. Added back copy and paste when a region is selected.
And removed cua-mode
.
Copy-paste into and out of calc is now working. Thanks. When I start emacs with a emacs -q -l emacs_test_startup.el
, where the contents of emacs_test_startup.el
are
(add-to-list 'load-path "/home/boo/random_stuff/ergoemacs-mode_main/")
(require 'ergoemacs-mode)
(setq ergoemacs-keyboard-layout "colemak")
(ergoemacs-mode)
I get the usual splash screen. If I type C-h k
to describe a key binding, nothing happens. If I repeat it, then it works properly. This is running with the latest commit 2ae2ebf.
I have the same issue. However, I am unsure what is causing it. For me it is a minor issue. I removed all the advices and I still had the same issue. I am unsure what is happening here.
It worries me, in the sense that this is the kind of bug which partially broke mu4e. Is it possible to turn off the command loop and see if it persists?
The latest 5689999 fixes the issue you observed for me...
The command loop still turns on for menu during key sequences and for the unchorded keys
It is fixed for me as well. Now the problem is that C-h '
gives me the error
ergoemacs-describe-current-theme: Symbol’s function definition is void: ergoemacs-theme-describe
Removed C-h '
Also added the M-
keys for term
. The Control keys are unbound. Since terms in xwindows use the alt keys to access menus, it could be similar to what you would use in a standard terminal...
Removed
C-h '
That is unfortunate. I find it really useful to have a way to show all of the current key bindings, because I definitely do not remember all of them. For new users, it is even more important. Is there something I could do to keep it working?
Also added the
M-
keys forterm
.
That is awesome. I was shadowing the control keys before, but this is much better. Now I can use nano in term
. Thanks.
What is the proper way to override a M-
key? For me, I want to globally set M->
to xref-find-references
. If I set it with
(global-set-key (kbd "M->") 'xref-find-references)
it gets overridden by ergoemacs, which undefines it.
To override ergoemacs-mode
keybinding you can use:
(define-key ergoemacs-user-keymap (kbd "M->") 'xref-find-references)
I haven't created a special keymap for user bindings when a region is active.
To use changes to the global map can be maintained, but is harder to maintain and slows the startup. It was removed.
That is unfortunate. I find it really useful to have a way to show all of the current key bindings, because I definitely do not remember all of them. For new users, it is even more important. Is there something I could do to keep it working?
I agree, but am a bit pressed for time. If you want, you can look at ergoemacs-theme-engine
. Most the code to generate an image is still there. I just tested it and it doens't work.
Once that is done, you can make a composed keymap and describe the keys easily enough to create a function that describes the keymap.
it gets overridden by ergoemacs, which undefines it.
FYI, it is not really undefined, it simply binds it to the undefined
function so it seems to be undefined...
To override
ergoemacs-mode
keybinding you can use:(define-key ergoemacs-user-keymap (kbd "M->") 'xref-find-references)
That works. I think that is enough as long as it is documented somewhere.
That is unfortunate. I find it really useful to have a way to show all of the current key bindings, because I definitely do not remember all of them. For new users, it is even more important. Is there something I could do to keep it working?
I agree, but am a bit pressed for time. If you want, you can look at
ergoemacs-theme-engine
. Most the code to generate an image is still there. I just tested it and it doens't work.
No promises, but I will look into it.
Running gnus, it got rid of the C-k
binding for gnus-summary-kill-same-subject
. Did you intend to override local mode C-
bindings? It left C-k
unbound.
Indeed this is "meant" to happen. C-k
is kill line in emacs
so it should be bound in the proper place in ergoemacs-mode
.
This is the consequence of not calculating each active keymap...
Of course you can calculate these bindings with ergoemacs-calculate-keybindings-for-both-themes
:
(ergoemacs-save-key-state 'gnus-mode-map (if (string-equal ergoemacs-theme "reduction")
(progn
(ergoemacs-define-key gnus-mode-map (kbd "M-d") 'scroll-down-command)
(ergoemacs-define-key gnus-mode-map (kbd "DEL") 'scroll-down-command))
(ergoemacs-define-key gnus-mode-map (kbd "M-d") 'scroll-down-command)
(ergoemacs-define-key gnus-mode-map (kbd "DEL") 'scroll-down-command)))
;; For gnus summary
(ergoemacs-save-key-state 'gnus-summary-mode-map (if (string-equal ergoemacs-theme "reduction")
(progn
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-d") 'gnus-summary-prev-page)
(ergoemacs-define-key gnus-summary-mode-map (kbd "DEL") 'gnus-summary-prev-page)
(ergoemacs-define-key gnus-summary-mode-map (kbd "<delete>") 'gnus-summary-enter-digest-group)
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-f") 'gnus-summary-enter-digest-group)
(ergoemacs-define-key gnus-summary-mode-map (kbd "<M-left>") 'gnus-summary-prev-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-J") 'gnus-summary-prev-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "<M-left>") 'gnus-summary-next-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-J") 'gnus-summary-next-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "C-M-d") 'gnus-summary-show-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-g") 'gnus-summary-kill-same-subject)
(ergoemacs-define-key gnus-summary-mode-map (kbd "<deleteline>") 'gnus-summary-kill-same-subject))
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-d") 'gnus-summary-prev-page)
(ergoemacs-define-key gnus-summary-mode-map (kbd "DEL") 'gnus-summary-prev-page)
(ergoemacs-define-key gnus-summary-mode-map (kbd "<delete>") 'gnus-summary-enter-digest-group)
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-f") 'gnus-summary-enter-digest-group)
(ergoemacs-define-key gnus-summary-mode-map (kbd "<M-left>") 'gnus-summary-prev-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-J") 'gnus-summary-prev-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "<M-left>") 'gnus-summary-next-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-J") 'gnus-summary-next-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "C-M-d") 'gnus-summary-show-thread)
(ergoemacs-define-key gnus-summary-mode-map (kbd "M-g") 'gnus-summary-kill-same-subject)
(ergoemacs-define-key gnus-summary-mode-map (kbd "<deleteline>") 'gnus-summary-kill-same-subject)))
There are more too:
(ergoemacs-save-key-state 'gnus-article-mode-map (if (string-equal ergoemacs-theme "reduction")
(progn
(ergoemacs-define-key gnus-article-mode-map (kbd "M-d") 'gnus-article-goto-prev-page)
(ergoemacs-define-key gnus-article-mode-map (kbd "DEL") 'gnus-article-goto-prev-page)
(ergoemacs-define-key gnus-article-mode-map (kbd "<delete>") 'gnus-article-read-summary-keys)
(ergoemacs-define-key gnus-article-mode-map (kbd "M-f") 'gnus-article-read-summary-keys)
(ergoemacs-define-key gnus-article-mode-map (kbd "M-t") 'backward-button))
(ergoemacs-define-key gnus-article-mode-map (kbd "M-d") 'gnus-article-goto-prev-page)
(ergoemacs-define-key gnus-article-mode-map (kbd "DEL") 'gnus-article-goto-prev-page)
(ergoemacs-define-key gnus-article-mode-map (kbd "<delete>") 'gnus-article-read-summary-keys)
(ergoemacs-define-key gnus-article-mode-map (kbd "M-f") 'gnus-article-read-summary-keys)
(ergoemacs-define-key gnus-article-mode-map (kbd "M-t") 'backward-button)))
Basically, since gnus is a large package, every keymap it binds would likely need some work-around keymap.
(ergoemacs-save-key-state 'gnus-bookmark-bmenu-mode-map (if (string-equal ergoemacs-theme "reduction")
(progn
(ergoemacs-define-key gnus-bookmark-bmenu-mode-map (kbd "M-d") 'gnus-bookmark-bmenu-backup-unmark)
(ergoemacs-define-key gnus-bookmark-bmenu-mode-map (kbd "DEL") 'gnus-bookmark-bmenu-backup-unmark)
(ergoemacs-define-key gnus-bookmark-bmenu-mode-map (kbd "<delete>") 'gnus-bookmark-bmenu-delete-backwards)
(ergoemacs-define-key gnus-bookmark-bmenu-mode-map (kbd "M-f") 'gnus-bookmark-bmenu-delete-backwards))
(ergoemacs-define-key gnus-bookmark-bmenu-mode-map (kbd "M-d") 'gnus-bookmark-bmenu-backup-unmark)
(ergoemacs-define-key gnus-bookmark-bmenu-mode-map (kbd "DEL") 'gnus-bookmark-bmenu-backup-unmark)
(ergoemacs-define-key gnus-bookmark-bmenu-mode-map (kbd "<delete>") 'gnus-bookmark-bmenu-delete-backwards)
(ergoemacs-define-key gnus-bookmark-bmenu-mode-map (kbd "M-f") 'gnus-bookmark-bmenu-delete-backwards)))
Probably this would be written over too. Another option is to send emacs keys and shuffle which keymaps are on similar to what the cua
mode does for the C-c
keys
I think it would be good to have a decent binding for gnus, since it is widely used. I use gnus regularly, so I will look into it. One thing I do not understand is why you have separate code for the reduction theme. The code looks identical to me. I also see this duplication in ergoemacs-install-comint-bindings
. Can I consolidate things, or is there something I am missing?
These are autogenerated. You can reduce it if you wish, there should be no consequence if they are duplicated.
There is an interactive function for calculating keybindings called ergoemacs-calculate-keybindings-for-both-themes
. If you select a keymap it will put in the ergoemacs-mode keybindings into that map.
However, the major mode keybindings for comint-mode
are not being respected either. So the inheritance is problematic right now.
keymap lookup is:
(or (if overriding-terminal-local-map
(find-in overriding-terminal-local-map))
(if overriding-local-map
(find-in overriding-local-map)
(or (find-in (get-char-property (point) 'keymap))
(find-in-any emulation-mode-map-alists)
(find-in-any minor-mode-overriding-map-alist)
(find-in-any minor-mode-map-alist)
(if (get-text-property (point) 'local-map)
(find-in (get-char-property (point) 'local-map))
(find-in (current-local-map)))))
(find-in (current-global-map)))
https://www.gnu.org/software/emacs/manual/html_mono/elisp.html#Searching-Keymaps
So, anything that adds a keymap
property, or in the overriding-local-map
or overriding-terminal-local-map
will override the ergoemacs-mode
keybindings.
This is why `isearch mode keys need to be changed, but comit-mode keys do not need to be changed.
I found another issue. I do an incremental search forward, then decide to search backward. The reverse search does not contain the search string that I was using.
Specifically, using colemak bindings, I type
M-o is
This highlights all occurences of is
in the buffer.
Repeating M-o
goes to the next result.
Now I decide to reverse the search. I type M-O
and is
should already be filled out as the search string. This worked in my version, but something broke it in your version.
Hm. It works for me....
Perhaps 500a2eb for you?
That did not fix it for me. I am running with -q -l emacs_test_startup.el
, where that elisp file is
(add-to-list 'load-path "/home/boo/random_stuff/ergoemacs-mode_main/")
(require 'ergoemacs-mode)
(setq ergoemacs-keyboard-layout "colemak")
(ergoemacs-mode)
I see the same problem with qwerty.
The keymap was generated from colemak. In colemak, the M-O
is the key so it is a bug in the key lookup for the standard theme. I corrected it manually, but I am thinking this would not actually work for the isearch
in the terminal unless the M-O
is updated there too. Something more general.
The M-O
for isearch backward should work for you now. Also C-h b
should show the ergoemacs->emacs keybindings when passing emacs keys.
I'm unsure where else they should be displayed.
M-O
works for backwards search. Thanks. C-h b
still does not show that M-d
will eventually end up calling gnus-summary-kill-same-subject
. It looks like it will delete the line, which is definitely different from killing everything with the same subject. I still think that a direct mapping would be better.
C-h b
still does not show thatM-d
will eventually end up callinggnus-summary-kill-same-subject
. It looks like it will delete the line, which is definitely different from killing everything with the same subject.
I tested with changes in the global-map
. Now I tested changes in the major mode map. Now they display for me.
I also added a function to pull the "correct" function for describe-key
I still think that a direct mapping would be better.
This reamap still be turned off with ergoemacs-mode-send-emacs-keys
. If you want to get back the C-k
, you can remove the undefined
references by turning off ergoemacs-mode-unbind-emacs-keys
.
I do have to say, it is complicated to overwrite ergoemacs-mode
keys where they stand based on direct mapping.
Still the key map lookup is broken for M-O
Everything seems to work for me, including the binding for M-O
. I am still concerned about too much magic, but I can live with it. Thanks.
Great.
If it gets too much, I have allowed the variables above, and maybe you can figure out some solution to allow keymaps.
Matt
Can you reach out to me via email so I can get your information for signing the FSF paperwork?
I just reached out to Stefan Monnier today about the agreement.