printing keymaps
zzkt opened this issue · comments
I've been using mugur to generate keymaps for the corne keyboard by formatting the output of the mugur--keymap-* commands (just mugur-mugur without writing to any files) which works as expected.
not sure if this covers everything (still having some issues with macros) but it's been useful for testing incremental changes to existing configurations...
(defun mugur-print-keymap (mugur-keymap)
"Use the MUGUR-KEMAP to generate the equivalent qmk C code.
MUGUR-KEYMAP is the user-side keymap with all the mugur-keys and layers."
(let ((qmk-keymap (mugur--transform-keymap mugur-keymap)))
(format"/* Macros */
%s
/* Tap Dances */
%s
/* Leader Keys */
%s
/* Combos */
%s
/* Layer Codes and Matrix */
%s"
(mugur--keymap-c-macros (mugur--qmk-keymap-macros qmk-keymap))
(mugur--keymap-c-tapdances (mugur--qmk-keymap-tapdances qmk-keymap))
(mugur--keymap-c-leader-keys)
(mugur--keymap-c-combo-keys)
(mugur--keymap-c-matrix (mugur--qmk-keymap-layers qmk-keymap)))))
Is this a request for a feature, namely, the mugur-print-keymap or similar?
I, for one, keep the generated keymap.c file opened in an Emacs window and refresh it after each call to mugur-mugur. It's a reasonable way to check what changed and do an "incremental changes" development for my keyboard.
I've been using an existing keymap.c which has sections that get overwritten by calling mugur-mugur so mugur-print-keymap can be used to generate a keymap to copypaste. It works ok as is, but there may be a "better way to do it" for example marking the file and only modifying the generated sections.
As a feature, it probably depends if you have any plans for extending/customising rules.mk and config.h...
mugur-mugur generates a new keymap, named mugur, by default.
You can change the name of this new keymap by modifying mugur-keymap-name (see the [configuration section])(https://github.com/mihaiolteanu/mugur#configuration)
I'm not sure how you've got into this,
I've been using an existing
keymap.cwhich has sections that get overwritten by callingmugur-mugur
Now I'm intrigued :)
Maybe you've set mugur-keymap-name to point to your existing keymap?
If that's the case, there is no need to do that. mugur generates all the files, including keymap.c, rules.mk and config.h. In short, it generates a fresh keymap, ready to be built and flashed on your keyboard. You don't need to add anything extra after calling mugur-mugur.
It's a different workflow I guess? The crkbd needs different rules & config than ergodox, andkeymap.c also contains settings for debuging and oled display. since the only thing I'm changing is the keymap it seems easier to work directly with that.
I've added a new, experimental feature to the add-mugur-regions branch which would take care of both this issue and #13
In short, you can define, or mugur defines it for you when you first generate a new keymap, a code region starting with START-MUGUR-REGION and ending with END-MUGUR-REGION within which mugur generates all the code. The rest it leaves intact. So you can have something like,
my code, I can do whatever I want here
// START-MUGUR-REGION
...mugur generated code,
keymaps, rules, macros, etc...
// END-MUGUR-REGION
...the rest of my hacks
It works for keymap.c, config.h and rules.mk, thus addressing #13, as well. That is, you can have anything not covered by mugur in your rules and config files and mugur will not touch them when you call mugur-mugur.
git checkout the said branch, test it, and let me know how it works!
looking good! I haven't tried anything too complex or pathological yet, I'll let you know how it develops.
Nik, how is this going?
Looks like the basics are working well (layout, layers and modifiers) but i'm having some problems with the macros generated from emacs keybindings. Not sure if it's keyboard specific or a bug...
e.g. the macro that mugur creates from split-window-below is SEND_STRING(SS_TAP(LCTL(X_X)) SS_TAP(X_2)) which causes an error with gmake. Using (C-x 2) in the keymap produces SEND_STRING(SS_LCTL(SS_TAP(X_X)) SS_TAP(X_2)) which works for me.
Yes, that was a bug, indeed. Good catch!
I've pushed a fix for it on master.
I've also pushed the add-mugur-regions branch on master.
Nik, do you have a complete mugur example for the corne keyboard that I can link (or, better, copy/paste) into the examples section of the README page?
Sure. I've added a WIP version at https://github.com/zzkt/crkbd feel free to copy/paste/edit as required...
I've added it,
https://github.com/mihaiolteanu/mugur#corne
I've seen you have the (M-x "magit" ent) for an emacs function that doesn't have a keybinding (I assume).
I've thought about a way to allow emacs functions without keybindings, also, by transforming such symbols into the M-x equivalent, like you did.
The code is straightforward,
(and (symbolp mugur-key)
(symbol-function mugur-key)
(mugur--keycode `(M-x ,(symbol-name mugur-key) RET)))
But with the current implementation, this M-x generated mugur-key gets handled by mugur-keycode, which, eventually, sees the initial emacs function again, and again creates a new M-x list, and on and on, until emacs errors.
I think it is doable, but with some adjustments.
looks good. something like (magit) could be nice.
also, the example is missing the closing ))) for completeness
You're right.
I did a sloppy job of copy/pasting.
Fixed.
looks good. something like
(magit)could be nice.
;; keybindings for mugur
(bind-keys
("<C-f3>" . magit)
...
)
Some improbable key combinations are nice here.
Then you can use magit as a mugur-key in your layout