You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Emacs's "Easy Customization" mode supports the ability to enter a comment about a variable setting. This is one "special mode," where the user would enter text with spaces. This might be a concern for other special modes, but I'm not sure.
Example:
M-x customize-variable RET tool-bar-mode RET
Click "State" button, and select "Add Comment".
Then click on (or TAB over to) the "Comment:" field to enter a comment.
Since it is a special Emacs mode, Meow sets MOTION as the default state in Custom-mode.
But this prevents entry of spaces in "Comment:" fields, because the MOTION state uses space bar as a leader key.
One has to do "M-x meow-insert RET" before entering the comment. It's only a minor annoyance.
---end of issue, beginning of praise---
:-D
I've only just started using this package, but I'm very impressed with how it handles modal editing.
I especially like how the suggested Dvorak layout mirrors bindings that are commonly-used in Emacs's special modes (dired, ibuffer, et cetera). This is very smart. It avoids both context-switching and having to rebind every single major-mode to match the modal editing layout. I had thought of trying to configure something similar to this. Your package already does it, plus so much more.
I wasn't familiar with Kakoune, so the selection-combined-with-movement paradigm is also quite interesting. It seems like it will be even more efficient than evil-mode, but I'm just getting used to it.
One other suggestion: I think it might attract more interest if you referred to the "suggested" layouts as "default" layouts and included them in the package (rather than requiring cut-and-paste from the readme). Instead of saying that the user must define their own layout, you could simply advise that it's trivial to change the layout as the user sees fit.
I think the layouts you've devised make great sense and are worthy of being "defaults."
The text was updated successfully, but these errors were encountered:
About the built-in layout, I may add them as suggested default when I think they are stable enough. I may also add some ergonomic-style layout like what xah-fly-keys does.
Besides, if you are a doom emacs user, you may also interested in
Was testing in a non-Doom config before, but I just merged my Meow settings with my Doom configuration. I'm quite used to the menu entries provided by Doom's ":editor evil" module.
So it will take some getting used to. But these bindings should help a lot.
Thank you for the suggested bindings and for the quick response!
Emacs's "Easy Customization" mode supports the ability to enter a comment about a variable setting. This is one "special mode," where the user would enter text with spaces. This might be a concern for other special modes, but I'm not sure.
Example:
M-x customize-variable RET tool-bar-mode RET
Click "State" button, and select "Add Comment".
Then click on (or TAB over to) the "Comment:" field to enter a comment.
Since it is a special Emacs mode, Meow sets MOTION as the default state in Custom-mode.
But this prevents entry of spaces in "Comment:" fields, because the MOTION state uses space bar as a leader key.
One has to do "M-x meow-insert RET" before entering the comment. It's only a minor annoyance.
---end of issue, beginning of praise---
:-D
I've only just started using this package, but I'm very impressed with how it handles modal editing.
I especially like how the suggested Dvorak layout mirrors bindings that are commonly-used in Emacs's special modes (dired, ibuffer, et cetera). This is very smart. It avoids both context-switching and having to rebind every single major-mode to match the modal editing layout. I had thought of trying to configure something similar to this. Your package already does it, plus so much more.
I wasn't familiar with Kakoune, so the selection-combined-with-movement paradigm is also quite interesting. It seems like it will be even more efficient than evil-mode, but I'm just getting used to it.
One other suggestion: I think it might attract more interest if you referred to the "suggested" layouts as "default" layouts and included them in the package (rather than requiring cut-and-paste from the readme). Instead of saying that the user must define their own layout, you could simply advise that it's trivial to change the layout as the user sees fit.
I think the layouts you've devised make great sense and are worthy of being "defaults."
The text was updated successfully, but these errors were encountered: