search

ergoemacs / ergoemacs-mode

ergoemacs-mode
ergoemacs.github.io/
GNU General Public License v3.0
293 stars 35 forks source link

Faster, more robust, less featured version #505

Closed wlandry closed 3 years ago

wlandry commented 3 years ago

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.

mattfidler commented 3 years ago

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.

wlandry commented 3 years ago

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?

mattfidler commented 3 years ago

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.

mattfidler commented 3 years ago

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.

mattfidler commented 3 years ago

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.

wlandry commented 3 years ago

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.

mattfidler commented 3 years ago

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)
mattfidler commented 3 years ago

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

mattfidler commented 3 years ago

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?

mattfidler commented 3 years ago

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.

http://ergoemacs.org/emacs/emacs_menu_app_keys.html

wlandry commented 3 years ago

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.

mattfidler commented 3 years ago

Also not sure if the following keys are handled in the gui vs terminal:

C-i, C-m, and C-[

wlandry commented 3 years ago

I just manually tested it, and it seems to work.

mattfidler commented 3 years ago

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.

mattfidler commented 3 years ago

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

mattfidler commented 3 years ago

As far as gradual ergoemacs themes, I am also OK not supporting them.

wlandry commented 3 years ago

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.

mattfidler commented 3 years ago

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:

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.

mattfidler commented 3 years ago

Also, have you signed the gnu FSF contract? That is needed to get this to elpa.

mattfidler commented 3 years ago

As a note, to align with the original principles of ergoemacs-mode the following will need to be added back:

wlandry commented 3 years ago

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.

mattfidler commented 3 years ago

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

Summary of things that may need some clarification

mattfidler commented 3 years ago

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.

mattfidler commented 3 years ago

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

mattfidler commented 3 years ago

No command loop: https://github.com/ergoemacs/ergoemacs-mode/blob/8cd55a01445bbbe1ef5361e127c0490617aa867b/ergoemacs-themes.el

mattfidler commented 3 years ago

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:

That being said, I am also inspired by your branch to:

Thank you again for you help and your interest

wlandry commented 3 years ago

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.

mattfidler commented 3 years ago

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.

wlandry commented 3 years ago

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.

mattfidler commented 3 years ago

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.

mattfidler commented 3 years ago

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

mattfidler commented 3 years ago

Merged the changes with the master. I will reach out to Stephan Monnier to see if he can send you the contract.

mattfidler commented 3 years ago

I forgot to tag you @wlandry

wlandry commented 3 years ago

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.

mattfidler commented 3 years ago

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

wlandry commented 3 years ago

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.

wlandry commented 3 years ago

M-x calc does not work for me. I get the error

Error running timer ‘ergoemacs-command-loop--timer’: (void-variable comint-mode-map)
mattfidler commented 3 years ago

It works for me... But I required comit to see if it fixes your problem

wlandry commented 3 years ago

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
mattfidler commented 3 years ago

Seems to be a cua-mode interaction. Added back copy and paste when a region is selected.

mattfidler commented 3 years ago

And removed cua-mode.

wlandry commented 3 years ago

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 2ae2ebfd799c5c9b4fa10f3e2797ebf6ed25851b.

mattfidler commented 3 years ago

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.

wlandry commented 3 years ago

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?

mattfidler commented 3 years ago

The command loop isn't enabled.... so I cant turn it off. I could turn it on though...

On Sun, Oct 10, 2021, 3:05 PM Walter Landry @.***> wrote:

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?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ergoemacs/ergoemacs-mode/issues/505#issuecomment-939544308, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5VWTJ7OPTAZKE7WRGOATUGHWXTANCNFSM5EJQUVEA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

mattfidler commented 3 years ago

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

wlandry commented 3 years ago

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
mattfidler commented 3 years ago

That needs to be removed. Themes are no longer described since the theme engine no lonfer exists...

On Sun, Oct 10, 2021, 8:59 PM Walter Landry @.***> wrote:

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

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ergoemacs/ergoemacs-mode/issues/505#issuecomment-939615364, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5VWT4QAQHXYSKQC2ZLATUGJAJ3ANCNFSM5EJQUVEA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

mattfidler commented 3 years ago

Removed C-h '

mattfidler commented 3 years ago

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...