aboutsummaryrefslogtreecommitdiff
path: root/users/ericgebhart/readme.md
diff options
context:
space:
mode:
Diffstat (limited to 'users/ericgebhart/readme.md')
-rwxr-xr-xusers/ericgebhart/readme.md1584
1 files changed, 0 insertions, 1584 deletions
diff --git a/users/ericgebhart/readme.md b/users/ericgebhart/readme.md
deleted file mode 100755
index 446a1411b4..0000000000
--- a/users/ericgebhart/readme.md
+++ /dev/null
@@ -1,1584 +0,0 @@
-Overview
-========
-
-This is as much a keymap framework as it is a keymap. It can take many
-shapes with just a few configuration choices. Base layers, Mods, thumb clusters,
-edge_keys, all can be changed with just a configuration option.
-There are over 50 base layouts to choose from, as well as multiple
-choices of navigation, mouse, media,
-symbols, and keypads. Home row mods come in a few flavors or none,
-in a mod layer which is easily understandable and can be turned on
-or off, or switched. There are Miryoku options for everything if
-that is your thing.
-
-If there is a oled of 64x128 the maps of each layer will be displayed, which
-helps a lot in remembering and learning.
-
-This is an easily configurable keymap for keymap exploration. It is for
-primarily for minimalist, ortho split keyboards but does support some rectangles.
-It´s first keyboard was an Ergodox-ez many years ago. My daily driver
-is now a Kyria or a Corne, but I still use an original dactyl, rebound
-and ergodox-ez regularly although most of the love goes to the Kyria and Corne.
-
-The framework is Language
-agnostic, it supports having layers for different locales which can be
-cycled through.
-There are multiple mods layers to choose or
-not, home row mods or not, a variety of thumb layouts, mouse/no mouse,
-smart lock layers and mods, N-Shot mods like callum's, swapper. Combos,
-tap_hold, accented keys, alternate shifted keys, automatic custom
-keys, key overrides. Minimal or no C-code required for most things.
-Language, mods, layouts and extensions are encapsulated, so that they
-do not interact in the configuration which makes it much easier to modify
-and grow. Mods and combos are by key location rather than specific key codes.
-
-Quick start
--------------
-
-Everything is encapsulated here. Base layers, functional layers, mods,
-or no mods, even the language. This means that anything can change
-independently and easily.
-
-If you don't mind dvorak, beakl or hands down, you can probably
-just use what is configured. Or just change it to a base layer
-of your choice. The fastest way to get started is to just change
-the base layers to the ones you want, compile and flash.
-
-Edit _config.h_,
- * Set the lang_is, probably to EN.
- * US international and BEPO are also supported out of the box.
- * Uncomment the base layers you wish to have.
- * comment the ones you don't.
- * keep the number below 5 if you enable a second locale.
- * Set the thumb clusters
- * Choose a mod layer
- * Choose an edge key set if you need one.
- * Choose the layer flavors that you want.
- * For Miryoku, copy the `miryoku_hd_gold_config.h` over `config.h`
- It is a complete config with miryoku choices. Choose the base
- layers you wish if Hands Down Gold and Qwerty is not your thing.
-
- ** do not turn off extensions until you know them **
- It will likely cause a stream of errors for the keycodes that
- go missing when something is turned off. There are known
- interactions between combos, smart locks, not_dead, and alt local keys.
- Turning encoders or oled on and off certainly won´t break
- anything.
-
- There are other interactions between your choices.
- Edge keys, thumbs, combos, other extensions,
- may use the extensions that are enabled.
-
-### Look here to see the parts
- * Everything can be turned on and off in *config.h*
- * Base layers are in *base_layers/*
- * Edge keys are in *layers/edge_keys.h*
- * Thumbs can be reviewed in *layers/thumbs.h*
- * Mods are in *mod_layers/*
- * All other layers are also in *layers/*
-
-
-The long version
------------------
-
-All can be turned on or off in the config.
-supports en-us and fr-bepo Support for other languages is easily added.
-
-Layouts are human readable, all extensions are defined with def files.
-If an 128x64 oled is available, a map of the current layer is shown if enabled.
-
-I'm an Xmonad, emacs in vi emulation programmer, that
-just means that _Gui, Esc, :/?!% and ._ are all easy access and I like my
-arrow and mouse keys in a 4 column row.
-
-I have also become minimalist in my keyboard choices. I don't use
-number rows, not even on my kinesis, dactyl, or ergodox_ez, which have them.
-Although my maps do reasonably support these bigger keyboards as that is where
-it all started for me and I do still use them. My preference for keyboards
-is more in line with the Kyria and Corne. I still use 6 columns, but have been
-looking to use only 5.
-
-Note: Combos at QMK master do not currently support multiple reference layers which this
-configuration uses. Combos still work as always, but do not support all the features
-found here. To get fully functioning multi-reference combos, see my *ericgebhart_dev*
-branch and pull request below.
-
-Actually, at the moment, the fix is in my ericgebhart branch, since I accidently
-pushed it. I'll remedy that soon.
-
-A more current version of my QMK user can be found here in
-A sparse tree [of my QMK User Space ](https://github.com/EricGebhart/MyQMK/users/ericgebhart)
-
-For full multi-lingual combo functionality you will need my [pull request for fully functioning multi-reference combos which can found here.](https://github.com/qmk/qmk_firmware/pull/16699)
-
-Things which effect the thinking.
- * No mouse.
- * Preference for 3x10 layouts. Corne, Kyria, etc.
- * Still works with bigger keyboards like xd75, kinesis, dactyl, ergodox, viterbi.
- * Change mods without changing any maps.
- * No number row preference. - all layouts have them if needed.
- * Xmonad window manager, GUI key is the entrance to the Xmonad world.
- * Typing in other languages.
- * Curious about keyboard layouts and experimenting.
- * Must be easy to maintain, extend and modify.
- * Minimize digging in code to add new things, or change old ones.
- * Minimize process record user.
- * Easy to add enums for keys and layers, as well as oled display.
- * Easy to support multiple languages regardless of maps.
- * Minimize the need to write C code.
- * Encapsulate C code, so that it is extensible through data.
-
-
-Features:
- * Everything is configurable from config.h and .def files.
- * Def files for most things.
- * Custom key codes are mostly defined automatically.
- * Everything is chosen or turned on and off in config.h
- * Lots of macros to make it easy to redefine things without a refactor.
- * Multiple edge/outer pinky column sets.
- * Multiple thumb clusters to choose from.
- * Thumb clusters and mods can be changed on a map by map basis.
- * Easily define thumb clusters with an alpha letter.
- * Easily define thumb clusters for non-base layer.
- * Multiple base layers to choose from.
- * Several variations of function layers to choose from
- * Miryoku layers, thumbs and mods if desired
- * Miryoku hands down gold config can be swapped with config.h
- * Navigation and mouse layers
- * A selection of symbol, keypads, and other layers.
- * Regular and Beakl keypad and number rows
- * Multi language support, (locales in the code).
- * Multiple mod layers to choose from. Easy to add more.
- * home row mods - a selection
- * no mods
- * alt mods
- * miryoku mods
- * Extensions are easily defined in def files.
- * N-shot mods
- * One-shot mods
- * swapper
- * Smart lock mods
- * Smart lock layers.
- * Accent keys
- * Alternate shift keys
- * Alternate local keys
- * key overrides
- * Tap hold
- * Not dead keys
- * Send unicode
- * Send string
- * Encoders
- * Display a map of the current layer on the oled.
- * Adding a new layer is painless.
- * Adding or changing most things, is not difficult.
- * Console key logging for [heatmap analysis.](https://precondition.github.io/qmk-heatmap)
-
-
-Layout shape and keyboard choices.
--------------------------------------
-
- In all cases these keyboards are defined in a matrix which is
- a set of rows. Maybe like so, or less. Kinesis has one more row.
-
-```
- -------------------------|------------------------ */
- | Left0 | Numbers L | mid|dle0 | numbers R | Right0 |
- | Left1 | keys0-5 | mid|dle1 | Keys6-10 | Right1 |
- | Left2 | keys11-15 | mid|dle2 | Keys16-20 | Right2 |
- | Left3 | keys20-25 | mid|dle3 | Keys25-30 | Right3 |
- | Row5L | Row5R |
- | ThumbsL | ThumbsR |
- -------------------------|------------------------
-```
-
-Generally speaking, the keys on the right and left and middle don't change.
-Neither do the bottom row or the thumbs, unless asked. Frequently the numbers
-row is identical across layers.
-
-For automatic edge columns set EDGE_COLS.
-Outside pinky keys are 'yes'. This is on by default.
-N rows by 6 columns per side.
-Should be undef/def'd by the keyboard's keymap if no.
-#define EDGE_COLS yes. this is all taken care of for supported keyboards.
-
-Thumbs and Edge keys are grouped into sets so that different sets can be chosen in
-the config.
-
-All layer macros take 3x10 or 3x12 as needed. Edge columns are
-added as needed, and middle keys fill up the gap.
-Thumb keys are added as asked.
-
-keyboard shapes:
-Matrix size + 5th row + thumbs.
-Matrix size + thumbs.
-
- * kinesis
- 4x6 + 4 + 6 - 18 func keys.
- * dactyl - Morpho handwire
- 4x6 + 5 + 6
- * ergodox_ez
- 4x6 + 5 + 6 & 3 pairs of center keys.
- * crkbd - corne
- 3x6 + 3 or 3x5 + 3
- * xiudi/xd75
- 5x15
- * keebio/viterbi
- 5x14
- * montsinger/rebound/rev4
- 4x12 + 3 center keys.
- * -- 4x12
- * splitkb/kyria
- 3x6 + 7 or 3x5 + 7
-
-The parts of a keymap
----------------------
-
- * keymap
- * defined in _keymap/keymap.c_.
- * Completely configurable from config.h
- * Separated into logical chunks.
- * Uses a language setting to create all maps.
- * Creates the same maps in multiple languages.
- * More than one language simultaneously on one keyboard.
- * Currently provides these languag settings and keycodes.
- * US - US-intl (US_)
- * EN - US-en (KC_),
- * BEPO - fr-bepo (BP_).
- * Choosing dvorak, and enabling bepo as the second locale,
- will produce two base layers to choose from on the keyboard.
- Dvorak on US and BEPO.
-
- * Base layers
- * Simple and compact definitions.
- * Base layers are pure.
- * Mods are defined separately.
- * OLED Maps for 128x64 sized oleds.
- * Language agnostic.
- * Core layer chunks are 3x10.
- * Except for few exceptions which are 3x12
- * More than 50 base layers to choose from.
-
- **Caution: Choosing too many base layers will result in toprows or keypad layer LT's
- to stop working. If bepo is enabled, all base layers are doubled so it's
- easy to hit the 16 layer limit for LT.**
-
- * Locales
- * Locales, defines a set of layers for a locale.
- * Layer definitions are language agnostic. - see lang.h.
-
- * Extensions - Defs.
- * Can be selected in config.h
- * Defined in easy to read .def files.
- * Correspondance between *extensions/* and *defs/*
-
- * accented_keys.def - direct access to altgr keys
- * altlocal_keys.def - alternate un/shifted pairs.
- * alt_shift.def - alternate shifting behaviors for existing keycodes.
- * not_dead.def - definitions for non-dead dead keys.
- * caps_word - no def file.
- * combos.def -
- * custom_keys.def - list of custom keys.
- * encoders.def - encoder behaviors by mod/layer.
- * key_overrides.def - Bigger more complex alt keys.
- * mod_lock.def - smart locking mods with a set of ignore keys.
- * nshot.def - N-shot locking mods
- * oneshot.def - One-shot locking mods
- * smart_lock.def - Smart lock layers and mods.
- * swapper.def - key substitution, reverser.
- * eg. toggle between tab, backtab on a key, with a reverse key.
- * tap_hold.def - Define key for tap and hold for tapping term for qqc autre.
- * unicode.def - keycodes to send unicode strings.
- * send_string.def - keycodes to send strings.
-
-
- * Layers
- * Multiple selections of the Transient layers.
- * Layer chunks are 3x10, with some options.
- * Full Navigation layer - stable and well used.
- * Mouse keys or without.
- * 1 or 2 layer nav, 2nd for mouse. or all on one. - choices.
- * Multiple choices of an easy to use _top rows_ layer similar
- to `raise` and `lower`.
- * A fully complete symbol layer, Used for coding and writing.
- * Accented letters and dead key layers.
- * Keypads and function pads.
- * Beakl keypads and symbol layers.
- * Control layers.
- * Layers
- * Adjust
- * RGB
-
- * OLED A simple, configurable implementation.
- * Current base layer
- * Current locale
- * Current transient layer
- * Last key, matrix location and value.
- * Mods and locks
- * Map of the current layer. (Oled 128x64)
- * key logger
-
- * Keyboards
- * nothing is needed in keymaps/*/keymap.c
- * Layouts - keyboard matrix adaptation.
- * Adaptive. Usually taking 3x10 maps and filling the edges and thumbs.
- * 4x10 or whatever is possible.
- * 3 versions, thinking in a split kb, way.
- * 5 columns in, 5 out.
- * 5 columns in, 6 out.
- * 6 columns in, 6 out.
- * per keyboard shape.
- * There are layouts per keyboard.
- * Base layout with mods and thumbs and edges added.
- * Transient layout which can be KC_TRANS, in those same places.
- * The number row addition can be turned on and off as needed by the layout.
- * Layouts can hard code the number row, negating the need for giving one.
-
- * Multiple edge key sets
-
- * Multiple Thumb clusters - see config or thumbs.h for up to date choices.
- * Support for multiple definitions.
- * mods
- * layers
- * mods_layers
- * mods_layers_nav
- * beakl wi
- * beakl wi - official.
- * test - to play with.
- * trans - transparent, could be used in the transient layout to allow alternates.
- * miryoku with keypad
- * miryoku with toprows
- * mods_layers with left thumb letter
- * hands down approximation with left thumb letter
- * miryoku with keypad, letter on left, space on right. - no tab.
- * miryoku with toprows, letter on left, space on right. - no tab.
-
- * Mod Layers
- * Completely independent of any layer or base layer definition.
- * Easy to create a new one by copying the transparent version.
- * Can be changed on a layer per layer basis.
- * Based on position in the matrix.
- * Chosen in config.
- * Multiple choices.
- * Home Row Mods. sacg, gacs, gasc
- Left and right mods on left and right.
- * Transparent - the default if not chosen.
- * Alt - Non home row mod variant.
- * miryoku HRMS is sacg plus right alt/altgr on third row.
-
- * Alternate language/locale support
- * Happens at the lowest level
- * All maps work with any of the [keymap extras.](https://docs.qmk.fm/#/reference_keymap_extras)
- * Language support is simple to add with just a new, very simple macro.
-
-The language keycodes can be found
-[here.](https://github.com/qmk/qmk_firmware/tree/master/quantum/keymap_extras)
-
-
-Architecture
------------------
-The idea here is that most things don't change, and the things that do are
-easy to understand and change. The defs directory is where all the extras are,
-tap_hold, alternate shift keys, combos, keycodes, smart lock, one shot mods,etc.
-
-If layers exist that you want and like, then all other behaviors are defined in
-def files which are much nicer than working directly with C code. If there is
-need there is always the copy pasta way too.
-
-Things that are likely to be changed when adapting a layout to personal preferences
-are *layers/thumbs.h* and *mod_layers/*. The function layers are all in the
-layers folder and should be easy to understand. Once added, it is only necessary to
-add the appropriate defines in _config.h_
-
-Adding new layers requires changes in layer_names, *oled/oled_layers.h* and *oled/oled_cartes.h* and the appropriate *keymap/ .h* file.
-
-Adding a new keyboard is done in keyboards and should be fairly obvious.
-```
-.
-├── base_layers
-│   ├── accents.h
-│   ├── alt.h
-│   ├── base_layers.h
-│   ├── beakl.h
-│   ├── bepo.h
-│   ├── carpalx.h
-│   ├── dvorak.h
-│   ├── gap.h
-│   ├── hands_down.h
-│   ├── keymaps.txt
-│   ├── maks.h
-│   ├── qwerty.h
-│   └── toprows.h
-├── config.h
-├── defs
-│   ├── accented_keys.def
-│   ├── altlocal_keys.def
-│   ├── alt_shift.def
-│   ├── combos.def
-│   ├── custom_keys.def
-│   ├── encoders.def
-│   ├── key_overrides.def
-│   ├── mod_lock.def
-│   ├── not_dead.def
-│   ├── nshot.def
-│   ├── oneshot.def
-│   ├── send_string.def
-│   ├── smart_lock.def
-│   ├── swapper.def
-│   ├── tap_hold.def
-│   └── unicode.def
-├── ericgebhart.c
-├── ericgebhart.h
-├── extensions
-│   ├── accented_keys.c
-│   ├── accented_keys.h
-│   ├── altlocal_keys.c
-│   ├── altlocal_keys.h
-│   ├── alt_shift.c
-│   ├── caps_word.c
-│   ├── caps_word.h
-│   ├── console_key_logger.c
-│   ├── console_key_logger.h
-│   ├── encoders.c
-│   ├── encoders.h
-│   ├── extensions.h
-│   ├── keycodes.h
-│   ├── keymap_combo.h
-│   ├── key_overrides.h
-│   ├── mod_lock.c
-│   ├── mod_lock.h
-│   ├── not_dead.c
-│   ├── nshot_mod.c
-│   ├── nshot_mod.h
-│   ├── oneshot.c
-│   ├── oneshot.h
-│   ├── process_locales.h
-│   ├── process_nshot.h
-│   ├── process_smart_lock.h
-│   ├── send_string.c
-│   ├── smart_lock.c
-│   ├── smart_lock.h
-│   ├── swapper.c
-│   ├── swapper.h
-│   ├── tap_dances.c
-│   ├── tap_dances.h
-│   ├── tap_hold.c
-│   ├── tap_hold.h
-│   ├── unicode.c
-│   └── unicode.h
-├── keyboards
-│   ├── keyboards.h
-│   └── layouts.h
-├── keymap
-│   ├── keymap.c
-│   ├── map_accented.h
-│   ├── map_alt.h
-│   ├── map_beakl.h
-│   ├── map_bepo.h
-│   ├── map_carpalx.h
-│   ├── map_dvorak.h
-│   ├── map_funcs.h
-│   ├── map_gap.h
-│   ├── map_hd.h
-│   ├── map_keypads.h
-│   ├── map_maks.h
-│   ├── map_qwerty.h
-│   ├── map_symbols.h
-│   └── map_toprows.h
-├── lang
-│   ├── lang.h
-│   ├── lang_map.h
-│   ├── locale_layers.h
-│   ├── locales.c
-│   └── locales.h
-├── layer_names
-│   ├── base_names.h
-│   ├── func_names.h
-│   ├── layer_names.h
-│   └── util_names.h
-├── layers
-│   ├── edge_keys.h
-│   ├── keypads.h
-│   ├── layers.h
-│   ├── nav.h
-│   ├── symbols.h
-│   ├── thumbs.h
-│   ├── toprows.h
-│   └── utility.h
-├── listen_keylogger.sh
-├── mod_layers
-│   ├── alt_mods.h
-│   ├── hrm_gacs.h
-│   ├── hrm_gacs_miryoku.h
-│   ├── hrm_gasc.h
-│   ├── hrm_sacg.h
-│   ├── hrs_nav.h
-│   ├── mod_layer.h
-│   └── trns_mods.h
-├── oled
-│   ├── oled_cartes.c
-│   ├── oled_layers.c
-│   ├── oled_stuff.c
-│   └── oled_stuff.h
-├── process_records.c
-├── readme.md
-└── rules.mk
-
-10 directories, 118 files
-```
-
-Locales
--------------------
-There are currently three locales. LANG_IS defines the one in use.
-The map changes this value as it goes, to get the maps that are asked for.
-I have recently renamed some variables, such that it seems that only 2 locales
-are possible. It seems more than two might be too many. And keeping at 2 is
-a little easier.
-
- * EN - en-us, **KC_** keycodes.
- * US-INT - us-international variant, **US_** keycodes.
- * BEPO - bepo-fr, **BP_** keycodes.
-
-Switching LANG_IS before adding a new map will cause that map to
-use LANG keycodes and keymap chunks when building the map.
-
-Enabling a second locale to bepo, will cause bepo versions of the chosen layers to
-be added to the keymap.
-
-### defining a locale.
-
-This is to manage BEPO and Qwerty Locale/language/Layers
-Each locale is defined with a start and end layer from the layers enum.
-
-This is only necessary to give contextual base layer choices based on
-the current locale setting, which the keyboard tracks.
-
-The first and last defines are all done with the magic of defines in
-ericgebhart.h where the layers enum is defined.
-
-This could potentially hold multiple locales, The map turns on off the layers
-and their enums if they are not enabled so that the layer array does not
-fill up with too many base layers, or other layers because LT only works
-up to layer 15.
-
-What this does is allow the keyboard to know which locales it has, and which
-layers go with them.
-
-If you have an oled, the locale will be displayed after the layout name. Currently
-en-us and bepo-fr are there.
-
-Locales are tracked, as to the layer ranges which belong to them in the layers enum.
-This allows for a `KC_NEXT_LOCALE` key and a `KC_NEXT_BASE_LAYER` key, on the _layers_
-layer.
-`KC_SET_BASE` sets the default layer in the eeprom.
-
-When cycling through layers only the layers for the chosen local will appear.
-
-The layers are different keycode sets.
-So there are two symbol layers, two toprows layers, two keypad layers.
-One for Qwerty and one for bepo. The Navigation layer is not affected because
-it has only control keycodes which are independent of locale.
-
-
-### Locales, how they work in layouts.
-
-This is done through consistent naming patterns and macros.
-Here are the macros that support creation of layout parts by locale.
-All are defined in **lang.h**
-
- * Keycode Prefix - KC or BP, etc.
- `LANG_KC(_A) -> KC_A or BP_A`
-
- * Defined key/layer Suffix - SYMB_EN, SYMB_BP, ...
- `LANG_N(NAME) -> NAME_EN, NAME_BP`
-
- * Map chunk Suffix - _EN, SYMB_BP, etc.
- `MAP_CHUNK(15_BOTTOM) --> ___15_BOTTOM_EN___ or ___15_BOTTOM_BP___`
-
-_lang.h_ has the macro definitions used in the keymap resolution,
-A new locale, will need a new set of macros that match the others.
-They use LANG_IS, Follow the patterns. It should be reasonably obvious.
-
-It is only necessary to create new base level macros that are used by these
-macros. All of them are similar.
-
-**LANG_KC** uses these macros to resolve it's values.
-```
- // Give the right keycode prefix by LANG_IS
- #define LANG_PFX CAT(LANG_IS_, KC)
- #define BEPO_KC BP_
- #define EN_KC KC_
-```
-
-Adding a new one is just a matter of adding the a macro named with
-this format. `LANG_IS _Keycode prefix`.
-for Slovak, if the **LANG_IS** value is `SK` that would be,
-
- `#define SK_KC SK_`
-
-LANG_N macro uses these similar macros for it's resolution.
-
-```
- // Give the right symbol suffix by LANG_IS
- #define LANG_SFX CAT(CAT(LANG_IS, _), SFX)
- #define BEPO_SFX _BP
- #define EN_SFX _EN
-```
-Adding Slovak support to the LANG_N macro looks like this.
-
- `#define SK_SFX _SK`
-
-
-### Thumb clusters.
-
-Thumb clusters can be chosen by layer with the value of **THUMBS_ARE**.
-
-The easiest way to see them is to look in *layers/thumbs.h*.
-
-At the core of the thumb clusters are a set of six keys which
-can be changed to a one of a set of keys, with settings in the config.
-Supporting a 4 key thumb cluster would just need a similar set.
-
-The newer Hands down variants also have need of thumb clusters which
-can take a letter. A default can be given in config.h.
-Each keymap layer entry can give it's letter to change the thumb cluster.
-This is needed for hands down, maltron, rsthd, and beakl wi.
-
-These layouts use a special thumb cluster variant which will use the value
-of *THUMB_LETTER* to place a letter on one of the thumb keys.
-
-It is reasonably easy to add a new thumb cluster and use it. Add it to
-thumbs.h, add to the list of macros for it's suffix, and turn it on
-by setting it to *THUMBS_ARE* in config.h
-
-Additionally a thumb cluster can be set for the various function layers as
-well. The transparent thumbs can be used, or something else. The nav and
-mouse layers have the mouse buttons if mouse keys are enabled.
-
-It is also possible to use a Miryoku thumb cluster and layers
-or mix the other layers in as desired.
-
-The language of thumb clusters is managed at the lowest level.
-These keys are mostly not language specific.
-
-Here is the definition for my space and symbol layer key.
-This changes the name of the layer given like this.
-
-_SYMB becomes *_SYMB_EN* or *_SYMB_BP*. Depending on the value of *LANG_IS*
-
- `#define SPC_SYMB LT(LANG_N(_SYMB), KC_SPC)`
-
-
-Edge key sets
-----------------
-Edge keys, or the 6th, and outer pinky column are often not specified
-in base keymaps and are not strictly necessary. There are a few sets
-to choose from here. A NOKC set with no keys, NORM which is sorta normal
-with grave, equal, tab, -, and \/. There is also a smart lock set
-which gives access to smart lock layers tab and -. Last there is
-test, so its easy to try new things. Edge keys are defined in
-*layers/edge_keys.h*.
-
-
-Base Layers
------------------
-I like to experiment with layouts. So I have a few.
-They can be turned on in config.h.
-
-To switch base layers there is a combo to raise the layers layer.
-Hold both pinkies on their lower row keys to get the layer.
-Tap the home row left middle finger to change layers.
-Tap the ring finger to set it to eeprom if you want it to stick.
-
-The left index finger will cycle through locales if you have them.
-
-Here is a list of some of the base layers..
-
- * Dvorakish
- * Dvorak
- * Capewell-Dvorak
- * Ahei
- * Boo
- * Dvorak RLC-UI
- * Beakl
- * 15
- * 19
- * 27
- * WI
- * Qwertyish
- * Qwerty
- * Azerty
- * Workman
- * Norman
- * Maks
- * Colemak
- * Colemak_DH
- * Halmak
- * Minimak
- * Minimak 8
- * Minimak 12
- * Carpalx
- * QFMLWY
- * QGMLWB
- * QGMLWY
- * Hands Down
- * Neu
- * Neu narrow
- * Titanium
- * Gold
- * Platinum
- * Silver
- * Bronze
- * Elan
- * Dash
- * Ref
- * MTGAP
- * Mtgap
- * Ctgap
- * Apt
- * Canary
- * Others
- * Maltron
- * Eucalyn
- * Rsthd
- * Isrt
- * Hands Up
- * White
- * Soul
- * Niro
- * Asset
- * Whorf
- * Whorf6
- * Bepo, layers with accented letters.
- * Bepo
- * Optimot
- * Optimot compact
- * Beakl19bis
-
-### Adding a new base layer, or any layer
-
-Adding a new base layer is easy. They all live in *base_layers/*. A base layer
-entry looks like this. There is an empty template in *base_layers.h* which collects
-all the other maps. The name of the carte de map, should be **CARTE** followed by
-the layer name that will be used. Layer names are usually an underscore followed by
-the name. For dvorak, that is *_DVORAK*, which because of the language layer ultimately
-and magically becomes *_DVORAK_EN*, *_DVORAK_US*, *_DVORAK_BP* as needed.
-
-```
-#define CARTE_DVORAK \
- carte_de_map(" ',.py fgcrl ", \
- " aoeui dhtns ", \
- " ;qjkx bmwvz ")
-
-#define ___DVORAK___ \
- LANG_MAP(TL_QUOT, TL_COMM, TL_DOT, _P, _Y, _F, _G, _C, _R, _L, \
- _A, _O, _E, _U, _I, _D, _H, _T, _N, _S, \
- TL_SCLN, _Q, _J, _K, _X, _B, _M, _W, _V, _Z)
-```
-
-#### TL_ keycodes
-
-Use TL_ keycodes for any punctuation, this allows for targeting
-of these keys by language and by target layout as needed.
-for instance *TL_COMM* -> TLKC(_COMM). The *Target-Language-comma*,
-becomes BP_BK_COMM, or KC_DV_COMM, US_HD_COMM, or whatever it
-needs to be based on current language and target layout. If your layer has special
-puncuation needs,
-
- * Add key entries to *altlocal_keys.def*
- * Edit to *lang/lang_map.h* to add the new *TARGET_PFX* entry.
- * Set the appropriate value to *ALT_TARGET_IS* in the layer's keymap entry.
-
-#### Integration
-
-Integrating the new map into the rest of the framework is just a simple entry
-in a few places.
- * *layer_names* needs to know about the new name so we can use it,
- * The oled needs to know about it so it can display it.
- * The config needs to know about it so we can turn it on.
-
-Follow these steps. Everything is very simple, and just one to 3 lines.
-Just follow the same patterns as all the rest.
-
- * Add the layer definition and map of the definition in *base_layers/<appropiate>.h*.
- * Add the layer name to *layer_names/base_names.h*
- * Add the layer name to *keymap/<appropiate>.h*
- * Add the layer entry to *oled/oled_layers.c*
- * Add the layer map entry to *oled/oled_cartes.c*
- * Add the define for the layer enable to *config.h*
-
-Adding a new functional layer follows the same patterns, although their
-keymap and oled entries may be more complex, since it is usually trying
-to pick one from a set of choices.
-
-### Adding a new thumb cluster configuration
-
-Adding a new thumb keys definition is done in *layers/thumbs.h*.
-The keys that change are just 6 and they all have the name of *___6_ERGO_THUMBS_...*.
-
- * Define a new thumb definition with a nice suffix like all the rest.
- * Add an entry to the *THUMB_EXT* list with the nice new suffix.
- * Set the appropriate *THUMBS_ARE* defines in config.h to it's
- new thumb extension name.
-
-### Adding a new mod layer
-
-This is also easy. Mod layers live in the mod_layers folder. Each file
-there is a separate mod layer, which is tracked in *mod_layers.h*
-The file, *trns_mods.h* is the transparent mods layer and by definition has
-no modifiers applied, providing a clean slate.
-
-The steps are these:
- * Make a new copy of an existing mod layer.
- * Edit the new file and change the names to your new name.
- * ie. *_trns* changes to *_my_new_mods*
- * Add the mods you want. MT's and LT's, tap holds, etc.
- * Edit *mod_layers/mod_layer.h*
- * Add the include for the new mods file*
- * Add the *MOD_EXT* entry for the new name
- * Define *MODS_ARE* in _config.h_ to use the new name.
-
-
-Keymaps
------------
-I only have one. It's in keymap/keymap.c.
-My config.h has all the current usable settings.
-Turn on the layers by enabling and choosing them in config.h.
-Most keyboards don't need a keymap.c.
-
-There are corresponding Bepo layers, as needed, which will arrive if *SECOND_LOCALE* is
-set to _BEPO_.
-This essentially doubles the number of keymaps.
-Nav, mouse, media, layers, RGB, and Adjust are not duplicated as there is no
-current need.
-
-## Mods, home row and otherwise.
-With all these layers it was a real pain to apply mods consistently and
-easily with the old wrapper code. So I changed the way I use keymap macro
-wrappers and added in my own mod layer. The only thing it has is the mods
-to apply. No more editing keymaps to apply mods. I do it once, and it
-works everywhere I want by location.
-
-Multiple versions are possible. Just copy the trns_mod_layer.h to a new
-name and modify it with a new extension name, (replace '_trns'). Then add it's include to mod_layer.h, to be used when the config says.
-
-The defines for *MODS_ARE* and *DEFAULT_MODS* determine which mods are applied
-to a given keymap layer.
-
-Keyboard matrix Layouts
------------
-This is where the keymap of the
-keyboard meets the mods and all the edge, middle and thumb keys, and makes
-it easy to give just a 3x10 definition for most layers regardless of which
-keyboard it is going to.
-
-To use an existing layout for a different keyboard, simply make an entry
-in *keyboards.h* to assign the proper layouts that fit that keyboard.
-So a planck could use the 4x12 layout out of the box. In the keyboards
-keymap there is only a need for config.h or rules.mk if something needs
-changing. For the keyboard an empty keymap.c will do.
-
-The base layout can be anything really.
-The base layer sets the thumbs and anything outside of the 3x10.
-The mod layer is wrapped in the base layout and adds the mods, and a 6th
-outer pinky column as needed.
-
-Some layouts take an extra number row.
-Layouts can be any shape, all of these take a 3x10, 3x12, 4x10 or 4x12,
-and make it fit the keyboard.
-
-The layouts defined in _layouts.h_ take a list of keys. and give them
-to the keyboard's layout. The Corne (crkbd), uses a layout called
- `LAYOUT_split_3x6_3`. So for the corne, I have a `Base_3x6_6` that
- is the same shape, in its resolution.
-
-There are layouts for Corne, ergodox, kinesis, dactyl, viterbi, xd75, rebound.
-
-Currently, 3 layouts are needed per keyboard.
- * A Base layout, for default/base layers,
- * A transient layout for the function layers.
- * A version which takes 3x12 for the larger bepo base layers.
-
-The base layouts can take 3 or 4 rows by 10 columns as desired.
-They add in the mods, and any pieces of matrix outside of
-the 3x10 center, function, numbers, lower rows, outside pinky keys,
-and thumb clusters.
-
-
-Functional layers
---------------------
-There are quite a few of these to choose from. The easiest way to see
-them all is to go look at them in _layers/_. They are logically divided
-into files, and their cartes/maps are easy to look at. There are
-minimalist Miryoku versions as needed.
-
-## Navigation Layer
-I do not use a mouse. I use Xmonad as my window manager, and I have
-practically no use for one. They are necessary however. So I have
-a Navigation layer which is all mouse, arrows, home, end, tab, page
-up, down, 5 mouse buttons and so on.
-
-There are a growing number of choices, left and right sided mouse layers
-right side arrows etc, and some monolithic nav layers like the one shown
-below.
-
-There is also a split layer, with arrows etc on the right, and smart mods
-and N-shots on the other. A left side mouse layer is accessible from
-the first nav layer. There are various choices at this point. It is
-best to look at the config.h for clues.
-
-The miryoku nav and mouse layers are somewhat but not terribly different.
-
-
-#### One of the Navigation layers.
-
-```
-M = Mouse
-B = Button
-W = Wheel
-AC = Acceleration
-CCCV = Tap -> Ctrl-C, hold for double tap duration -> Ctrl-V
-CTCN = Tap -> Ctrl-T, hold for double tap duration -> Ctrl-N
-CWCQ = Tap -> Ctrl-W, hold for double tap duration -> Ctrl-Q
-HOME = TAB & PGDN
-END = BKTAB & PGUP
-Lock/Unlock LAYER = PGDN & PGUP
-
-MB5 MB4 MB3 MB2 MB1 MAC0 | CTCN MB1 MB2 MB3 MB4 MB5
-TAB MLeft MDown MUp MRight MAC1 | CCCV Left Down UP Right TAB
- WLeft WDown WUp WRight MAC2 | CWCQ TAB PGDN PGUP BKTAB
-
- Left Down Up Right CCCV | CCCV MLeft MDown MUp MRight
-
-
-```
-
-
-## Symbol Layer
-
-The symbol layer is based on the Beakl15 symbol layer. It was very similar to a symbol
-layer that I had before beakl, but this felt better, and has been through a few
-iterations at this point. Vi likes using :/?! a lot. The = is not that important to
-me, as the : for the vi ex: command. The ! is very satisfying in this location.
-
-For US-intl and Bepo which have dead keys, the symbol layer uses the *not_dead* extension
-to give _'`"^~_ which are not dead.
-
-The beakl symbol layer is intuitive and fairly easy to remember. There are 3 versions.
-The original, an extended, and an extended and enhanced for vi.
-The primary purpose of the extension was to provide keys which might not be available
-elsewhere on the default layer. The vi version takes this further and moves :/?
-to better places.
-
-I prefer a modified beakl15 symbol layer. here it is, left and right.
-This layer has some extra characters so it works with non-beakl base layouts.
-The beakl wi symbol layer is not an improvement on this IMO.
-Miryoku symbols layer is only left sided, and minimalist as well.
-This might be a little vi centric, with the : in the middle. ymmv.
-
-There are a few choices, this is one.
-
-```
- `<$>' ?[_-]
- - \("#) !{:/} ;
- @=*+; %&^~|
-```
-
-
-## TopRows Layer
-
-The toprows layer is a nice way to transition to small keyboards.
-I think, truly this is the layer that makes tiny keyboards accessible in the beginning.
-Everything can remain familiar. I use this one with a beakl number row.
-The default, if no choices are made, aside from enabling toprows, will
-have a normal qwerty number row, as in the second map.
-
-I do not use F keys, The latest addition has _smart_ and _nshot mods_ in the third row.
-There is a miryoku thumb cluster which uses this layer instead of a keypad.
-
- ```
- !@#$% ^&*()
- 40123 76598
- F1 --- F10
- ```
- or
-
- ```
- !@#$% ^&*()
- 12345 67890
- F1 --- F10
- ```
-
-## Keypad and Funcpad Layers
-
-There are several variations of keypads and function key pads in various sizes,
-and left and right.
-There are also versions with smart and nshot mods instead of F-keys.
-There are monolithic, left and right, and also half keyboard left mostly...
-A miryoku version also exists.
-The keypad can be chosen in config.h.
-
-```
- 523: F9-12
- 7.104 F5-8
- /698, F1-4
-```
-## Media Layer
-
-A simple Miryoku, media layer, controls on the right.
-
-OLED
---------------------
-The oled shows the basic stuff I could find in most places.
-* Default layer
-* Current layer
-* Locale
-* Mods
-* Locks
-* Last key pressed
-* Map of the current layer as simply as possible. (128x64)
-
-Process_records.c
---------------------
-This is where the keycodes are processed...
-It tends to be where cruft gathers. Mostly I try to keep it empty
-and do all my processing with the extensions. The file, _extensions.h_
-takes care of inserting them in process_records with it's macro.
-
-
-Extensions
----------------------
-Extensions are all in the extensions directory and have a single
-entry point via extensions.h which provides a macro to place in **process_record_user**.
-The intention is that they are easy to copy and use as is without digging around
-in the C code. Custom keys are also defined there. Any keycodes defined by
-an extension are automatically added to the custom keys enumeration so there is no need to define them manually.
-
-A new extension can be added with a process record entry in
-extensions.h. Just follow the same code pattern. If an extension defines keycodes,
-add it's include entry in *keycodes.h* so that they are automatically added to the enum.
-Keycodes.h is also where all the miscellaneous short cut key defines are done.
-
-To copy all the extensions,
- * Copy the extensions and defs folders,
- * Copy process_records.c file or adapt yours.
- * Adapt your custom keycodes to custom_keys.def.
- * Copy the pertinant parts of config.h so that everything can be enabled.
- * Define _USERSPACE_H such that all the extensions can find your stuff.
-
-To adapt to your own process_record_user do this;
-Include extensions.h in your process_record_user,then add this
-above the switch.
-```
-PROCESS_EXTENSIONS
-```
-This will cause process records to use whatever extensions are turned on.
-
-Many extensions have a _.def_ file in _/defs_ for any data that is needed.
-
-Because many of them use custom keycodes or layers in their definitions,
-it is necessary to include your userspace .h such that keycodes and layer
-codes can be found. To simplify this, simply add a define to config.h
-to point at your .h or wherever your custom codes can be found.
-
-In my case;
-```c
-#define USERSPACE_H "ericgebhart.h"
-```
-
-
-Custom keys
--------------------
-The Custom keys are in __custom_keys.def__.
-
-__keycodes.h__ is an extension of sorts. It is the custom keys enumeration.
-The __custom_keys.def__ has a few random keycodes in it.
-
-All other keys are automatically generated from the other def files.
-
-For the extensions that have key definitions those keys are enumerated
-automatically. The keys are defined in the def files so there is no need
-to add them to the enumeration manually.
-
-It will complain as usual if there are duplicates.
-
-Mostly, __keycodes.h__ is key defines to make shortcuts, since the enumeration
-is done almost completely automatically. When adding a new extension
-which defines keycodes, that extension will also need an entry in
-keycodes.h in order to automatically define the new key enumerations
-it´s def file creates.
-
-
-Accent keys
------------------
-This is a way to create keycodes which access keys
-which are normally only accessible with an Altgr/Ralt and a dead key.
-
-Each definition takes a keycode, the key to modify, and the dead key
-to apply to it.
-
-```
-ACCENTED(BP_OCIR, BP_O, BP_DCIR)
-ACCENTED(BP_ACIR, BP_A, BP_DCIR)
-```
-
-
-Alternate keycodes
------------------------------
-Normally, a keycode has unshifted and shifted key values. These are defined
-by the OS and it's locale, not the keyboard. This feature allows a keycode
-to be defined that uses arbitrary unshifted and shifted keycodes and their modifiers.
-This is necessary, because, for instance, qwerty has , and ; paired. Other
-locales may not. Bepo, and Beakl both have different pairings as do many other
-layouts.
-
-Because of wanting dvorak and beakl on bepo there was the necessity to create keys
-from keycodes which were not combined. key overrides were not
-sufficient because some keys are not actually keys that can be accessed
-without modifiers. Each keycode for the new key specifies it's own
-modifiers making any character available as an unshifted or shifted key.
-
-Alternate keys for a locale, are defined in **altlocal_keys.def**.
-These are to emulate a key, from 2 keycodes.
-
-This is for emulating keys on another locale/language.
-Dvorak on Bepo-fr, or Qwerty on sk-SK, or de_DE.
-
-It is also good for alternate shifted and unshifted pairs like
-what is needed for beakl or hands down on en-us/qwerty.
-
-This feature is usually only needed for punctuation keys
-and the top row number keys. Where the unshifted and shifted keys
-are not the same character as the keyboard local on the OS.
-
-It has turned out that most of these keys have a destination language,
-and a target language/layout.
-The target is to emulate something on some language. QMK uses keycode prefixes,
-so this works pretty well and the names stay consistent with all the others,
-but with a middle name.
-
-The pattern is Language prefix, target language prefix, name.
-The target prefix is made up. BK -> beakl, DV -> dvorak, HD -> hands down, etc.
-
-The naming pattern is only important in that it works with all of the Lang
-macros elsewhere in this userspace. A macro is provided on a per key
-basis, which can be used at the base layer definition, such that *TL_COMM*;
-target-language-comma, becomes BP_BK_COMM, or KC_BK_COMM, or whatever it
-needs to be based on
-current language and target layout.
-
-Here is a def entry to create the 1/! keycode for dvorak in the Bepo-fr locale
-in *altlocal_keys.def*.
-```
- MK_KEY(BP_DV_1, BP_DQUO, MOD_LSFT, BP_DCIR, MOD_LSFT)
-```
-
-Here is what some Beakl keys look like for en-us/qwerty.
-Beakl has dot with @, comma with ! and " with `.
-
-In *altlocal_keys.def*.
-```
- // Keys for BEAKL on Qwerty
- MK_KEY(KC_BK_DOT, KC_DOT, MOD_NONE, KC_2, MOD_LSFT)
- MK_KEY(KC_BK_COMM, KC_COMMA, MOD_NONE, KC_1, MOD_LSFT)
- MK_KEY(KC_BK_QUOT, KC_QUOT, MOD_NONE, KC_GRV, MOD_NONE)
-```
-
-Not Dead keys
---------------------
-As a writer dead keys give me access to accented letters in other languages,
-As a programmer they are a pain, especially for a vi user. This problem is
-limited to a few characters; "'`^ and ~. This extension helps to fix these
-characters and make them accessible as non-dead keys. It does this by adding
-a space afterward. The space is eaten by the OS keyboard driver and the letter
-emerges as needed. Here are some non dead keys for US-Intl.
-In use, I put these on the symbol layer, and let all the others remain dead.
-
-```
-NOT_DEAD(US_DQUO_ND, US_DQUO)
-NOT_DEAD(US_GRV_ND, US_GRV)
-NOT_DEAD(US_QUOT_ND, US_QUOT)
-NOT_DEAD(US_CIRC_ND, US_CIRC)
-NOT_DEAD(US_TILD_ND, US_TILD)
-```
-
-Alternate shifts
----------------------
-The alt shift extension is very simple, it uses a usual keycode, it does
-not define custom keys. It allows for an existing key like dot or semi-colon
-to have a different letter on its shifted value.
-
-There are currently three types of shift mods.
- * Give a different character than usual on shift.
- * Give two of the usual character instead of one.
- * Give three of the usual character instead of one.
-
-They are all defined in *defs/alt_shift.def*.
-Here are some silly examples.
-
-```
-ALT_SHIFT(US_EXLM, US_PERC)
-SHIFT_FOR_2(US_AT)
-SHIFT_FOR_3(US_DLR)
-```
-
-
-Key Overrides
--------------------
-These are the standard QMK key overrides. For un/shifted pair keys *altlocal_keys* is
-much, +3x, smaller and direct in that it makes keycodes that can be placed anywhere.
-However, if ko's are desired, this extension is an easy place to start.
-
-There are nice macros which take care of defining everything that is possible
-with the ?_ko() functions
-
-This first example is better done with **altlocal_keys**.
-
-```
-// KOL(slash_pipe, MOD_MASK_SHIFT, KC_SLSH, KC_PIPE, _DVORAK_EN)
-```
-
-Other key overrides can be defined with these.
-
-```
-KO(name, mods, key, replacement)
-
-KOL(name, mods, modded_key, replacement, layer)
-
-KOLN(name, mods, key, replacement, layer, neg_mods)
-
-KOLNO(name, mods, key, replacement, layer, neg_mods, options)
-```
-
-Combos/Chords
-----------------------------
-
-The combos here use multiple reference layers which is a pending
-pull request in the dev branch of QMK. The combos here will still work
-to an extent if *COMBO_ONLY_FROM_LAYER* is set to the correct layer number.
-
-[See my pull request to enhance combos here](https://github.com/qmk/qmk_firmware/pull/16699)
-
-This pull request defines a hook function for combos to determine the
-reference layer for the current layer. This allows for multiple reference
-layers to be used depending on the situation.
-
-Reference layers will be created and used according to the following
-defines.
-If the reference layer is enabled, it will automatically be assigned to
-COMBO_REF_DEFAULT and that will be the default reference if none
-is specified. If not specified, the reference will be the current layer.
-
- * #define COMBO_REF_LAYER_ENABLE // enable a reference layer.
- * #define COMBO_REF_LAYER_TWO_ENABLE // enable a second reference layer
- * #define COMBO_ONLY_FROM_LAYER 2
- * #define COMBO_REF_DEFAULT 2
- Works in config.h if you know the number of your layer.
- Automatically set if ref layer is enabled.
-
-Defining layer specific combo reference layers by layer in combos.def
-In this case, the default will be _COMBO_REF, the NAV layer will
-reference it's self, while bepo dvorak will reference the second
-combo reference layer. Keys start or end with CB or CB2.
-
-```
-COMBO_REF_LAYER(_DVORAK_BP, _COMBO_REF2)
-COMBO_REF_LAYER(_NAV, _NAV)
-```
-
-The combo reference layers follow an easy to remember keycode naming
-convention so that it is easy to define combos based on position.
-Keycodes are prefixed by CB or CB2, the first number is the row,
-followed by L or R for left and right, then the column number,
-for each hand left to right.
-
-Row 0 is the number row, there are 4 rows possible.
-
-`CB_1L1` is the left pinky, `CB_1R1` is the inside right hand index column.
-
-```
- _1L1, _1L2, _1L3, _1L4, _1L5, _1R1, _1R2, _1R3, _1R4, _1R5,
-```
-
-If there are edge keys, they are named accordingly, left and right.
-
-```
-L0_CB, L1_CB, L2_CB, L3_CB
-R0_CB, R1_CB, R2_CB, R3_CB
-```
-
-Thumb keys use the COMBO and COMBO2 thumb settings which give keycodes
-like this.
-
-```
-#define ___6_ERGO_THUMBS_COMBO___ CB_TH1, CB_TH2, CB_TH3, CB_TH4, CB_TH5, CB_TH6
-#define ___6_ERGO_THUMBS_COMBO2___ CB2_TH1, CB2_TH2, CB2_TH3, CB2_TH4, CB2_TH5, CB2_TH6
-```
-
-Tap-Hold
------------------------
-
-Tap hold currently has *tap_taplong* and *open_openclose* functions.
-These are in *tap_hold.c*, *tap_hold.h* and *tap_hold.defs*.
-Both use **TAP_HOLD_TERM** as the hold duration.
-
-Tap_taplong sends one keycode on tap, and another after a hold of tapping term.
-Open_openclose, sends one keycode on tap, hold sends that, plus the second,
-followed by a back arrow.
-
-Additionally, open_openclose will send a triple of the open keycode when tapped with
-the shift modifier on.
-
-There as also a __not dead__ version of open_openclose that accomodates using
-dead keys like quote so that the functionalty behaves as if the key were not
-a dead key, giving a quote, a pair of quotes or a triple of quotes.
-
-The file _tap_hold.defs_ contains all the definitions. Like combos,
-these entries are processed with a function call from **process_user_record**
-`process_tap_hold_user(keycode, record);`
-
-Define your keys in *tap_hold.defs*.
-
-Here is Ctrl-C, Ctrl-V, as tap and long tap.
-```
-TP_TPL(KC_CCCV, LCTL(KC_C), LCTL(KC_V))
-```
-
-For tap open, hold for open and close then a back arrow.
-Here is __(__ or __()__ with tap and long tap.
-
-```
-OPEN_OCL(KC_OCPRN, KC_LPRN, KC_RPRN)
-
-OPEN_OCL(KC_OCQUOT, KC_QUOT, KC_QUOT)
-// non dead version of quote.
-OPEN_OCL_ND(BP_OCQUOT, BP_QUOT, BP_QUOT)
-OPEN_OCL_ND(US_OCQUOT, US_QUOT, US_QUOT)
-```
-
-It is also possible to trigger a smart lock with a hold.
-This example creates a keycode, `ENTNAV` which can be used
-to type enter, or smart lock the nav layer.
-Note that `SML_NAV` should be defined in `smart_lock.defs`.
-
-__Caveat:__
-This does have the unfortunate behavior of delaying the action
-until key up. So it may not be that useful. I did not like it
-for this particular example.
-
-```
-TP_SML(ENTNAV, KC_ENTER, SML_NAV)
-```
-
-Caps Word
--------------
-This is a slightly modified version of caps word which adds a *CAPS_WORD_ON* keycode
-which can be used to turn caps word on explicitly. This is useful for mapping a
-single key or creating a combo.
-
-[As documented in here.](https://getreuer.info/posts/keyboards/caps-word/index.html)
-Holding both pinkies on home row for double tapping term, is effectively
-right-shift and left-shift, invokes caps-word. The next word will be capitalized.
-It continues until it shouldn't.
-
-Smart lock
-----------------
-They are defined in *smart_lock.def*. They need
-a custom keycode, and a layer or mods, not mod keycode, to apply,
-followed by a list of keycodes to ignore and stay active.
-This allows popping to layer which will stick until it doesn't.
-Or to apply mods until it shouldn't. Each definition has it's
-own list of key codes to ignore. Derived from _smart_layers_
-by @possumvibes.
-
-Add a keycode to custom_keys.def then assign it to it's action in smart_lock.def.
-```
-// SMLL = smart lock layer.
-// SMLM = smart lock mod.
-
-// Keycode, layer/mod.
-// list of keycodes to ignore.
-
-SMLM(SMLM_LSFT, MOD_LSFT,
- ___VI_ARROWS___,
- ___HOME_PGDN_PGUP_END___,
- ___TAB_PGDN_PGUP_BKTAB___,
- ___SML_MODS_L___)
-
-SMLL(SML_NAV, _NAV, ___NAVA_3x10___)
-
-```
-
-Mod lock
-----------------
-Mod lock is originally from @possumvibes, it has ignore keys as well,
-but these keys apply to all locks defined. which gives a slightly smaller
-memory footprint than smart locks. The mods, are keycodes, rather than mod codes.
-
-The behavior is the same as smart lock mods, but less flexible, and smaller.
-First create a keycode in custom_keys.def, then assign it to the mod you want.
-
-Ignore keys are universal for all mod locks.
-
-```
-// mod lock keys. takes keymods not mods.
-// keycode should be defined in custom_keys.def.
-// custom key, modkey to activate
-MODL(ML_LSFT, KC_LSFT)
-MODL(ML_LCTL, KC_LCTL)
-MODL(ML_LALT, KC_LALT)
-MODL(ML_LGUI, KC_LGUI)
-
-// Keycodes which will NOT cancel mod lock mode.
-IGNORE_KC( KC_LEFT)
-IGNORE_KC( KC_RGHT)
-```
-
-N-shot mods
-----------------
-I simply modified N-shots to use a def file. This is essentially @possumvibes
-fancier version of @callum's one shot mods. It has ignore and cancel keys,
-and there are one shot mods or N shot mods. Ignore and cancel keys apply
-to all oneshot and n-shots.
-
-```
-// Define keycodes in custom keys.
-// KEYCode, mod keycode, to set for n-shot.
-// ONESHOT is for one.
-// NSHOT takes a count.
-
-// oneshots
-ONESHOT(OS_LSFT, KC_LSFT)
-
-// N-Shots
-NSHOT(TS_LCTL, KC_LCTL, 2)
-
-// Keys which will cancel the n-shots.
-CANCEL_KEY( PANIC)
-
-// Keys which will be ignored by n-shots.
-IGNORE_KEY( SML_NAV)
-```
-
-One-shot mods
-----------------
-This code came by way of @jurgen-kluft, I encapsulated the code and made
-the user functions definable with a .def file. This is similar to N-shots.
-This one keeps track of the last key consumed which helps it's decision making.
-It also has cancel and ignore keys like N-shots.
-
-Essentially the same as n-shots, but with less elegant C code. Choose one or
-the other.
-
-In evaluation. The code for nshots is better.
-
-```
-// custom-key, Oneshot name.
-ONESHOT( OS_LSFT, ONESHOT_LSFT)
-
-// keys to cancel
-CANCEL_KEY( KC_ESC)
-
-// keys to ignore.
-IGNORE_KEY( SPC_NAV)
-```
-
-Swapper
-----------------
-I added the defs code so they are easy to define. This is a way to
-alternate between 2 keycodes for a key by sending another keycode. An
-example is tab or backtab on one key, which reverses when you press a
-second key. It also allows for mods to be applied. The following defines
-SW_WIN, which sends left alt-tab and shift- left alt- tab, when reversed
-by SW_REV.
-
-```
-SWAPPER_KEY(SW_WIN, SW_REV, KC_TAB, S(KC_TAB), KC_LALT)
-```
-Note: The switch key is not automatically defined in the custom keys enum in
-_keycodes.h_. It is convenient to use the same one which causes problems
-for automatically adding it. Add it to *custom_keys.def*
-
-Encoders
-----------------
-This is basic encoder stuff, modified to use a def file which makes it a lot easier
-to define and use. It can switch the encoder functions based on layers and mods.
-Give it a layer name and/or mods to match on, and the clockwise and counter
-clockwise keycodes to send.
-
-I used LEFT and RIGHT, but really it's just 0-N, but I happen to have one
-on the left and one on the right. If you have one, use 0 or LEFT.
-
-The code scans the entries for matches on layer first, checking for a match for
-mods. If an encoder entry is not found it then scans for entries with
-layer set to LAYER_NONE.
-
-RGB light controls require calling the functions directly, for this
-there is a special macro and function that does this. The functions
-should take no arguments.
-
-```
-// Layer/none, encoder index 0/1, CW_KC, CCW_KC, Qualifying mod or none
-// LAYER_NONE and MOD_NONE for a single use.
-// LEFT and RIGHT for index. they go on from there, 2, 3, etc
-// if one encoder, LEFT/0, is the first one, on the master side.
-
-// default encoders, all layers no mods.
-ENCODER_ACTION(LAYER_NONE, RIGHT, KC_PGDN, KC_PGUP, MOD_NONE)
-ENCODER_ACTION(LAYER_NONE, LEFT, KC_DOWN, KC_UP, MOD_NONE)
-ENCODER_ACTION(LAYER_NONE, LEFT, KC_PGDN, KC_PGUP, MOD_LSFT)
-
-// Symbol layer encoders.
-ENCODER_ACTION(_SYMB, LEFT, KC_LEFT, KC_RIGHT, MOD_NONE)
-
-// RGB function encoders
-ENCODER_FUNCTION(_RGB, LEFT,
- rgb_matrix_increase_speed_noeeprom,
- rgb_matrix_decrease_speed_noeeprom, MOD_NONE)
-```
-
-
-Unicode
-----------------
-This is just the basic unicode example everyone seems to have.
-Add your keys to send unicode strings like so.
-
-```
- UC_STR(UC_DISA, "ಠ_ಠ")
-```
-
-Send_string
---------------
-This is just basic send string functionality using *SEND_STRING* and
-*SEND_STRING_DELAY*. Each entry defines a key to send a string.
-
-```
-SEND_STR(MYKEY, "this is a test")
-SEND_STR_DELAY(VRSN, QMK_KEYBOARD ":" QMK_KEYMAP " @ " QMK_VERSION ", Built on: " QMK_BUILDDATE)
-```
-
-Console key logging - for heat maps.
-----------------------
-Both CONSOLE_ENABLE and CONSOLE_KEY_LOGGER_ENABLE must be enabled for this to work.
-
-This is a console key logger which can save keys typed for analysis of keymaps
-using Vlad/Precondition's heat map tool. The code for the logger came from
-[here](https://precondition.github.io/qmk-heatmap#how-to-collect-the-required-data)
-The explanation and use of the heatmap is [here](https://precondition.github.io/qmk-heatmap)
-
-There is a script ```listen_keylogger.sh``` which should be run to collect
-the keylogger data.
-
-This does require **hid_listen** to be installed on the computer.
-On Arch linux this can by installed from the AUR with ```yay -S hid_listen```
-
-The output can also be seen just by using ```qmk console```.
-
-Note: _print.h_ is automatically included when CONSOLE_ENABLE is set. This allows
-for debug messages anwhere in the code base as needed to see what might be going
-on.
-
-Tap Dance
---------------------
-I had a lot of tap dance, It's turned off. It's big. tap-hold works pretty well most of the time, instead.
-My favorites were tab-backtab, home-end.
-