tutorial.kbd

#| --------------------------------------------------------------------------

                              KMonad: Guided tour

  Welcome to the KMonad configuration tutorial. This document aims to explain:
  1. The configuration syntax
  2. The required information
  3. All possible configuration options

  This document should be a runnable configuration, so with some tweaks to the
  `defcfg` block (see below) you should be able to try out all the examples
  interactively.

  -------------------------------------------------------------------------- |#


#| --------------------------------------------------------------------------

                     Basic syntax: comments and parentheses

  KMonad's configuration language is styled on various lisps, like scheme or
  Common Lisp. In a lisp, every statement is entered between '(' and ')'s. If
  you are more used to Fortan style languages (python, ruby, C, Java, etc.), the
  change is quite straightforward: the function name moves into the parentheses,
  and you don't use commas to separate arguments. I.e.

  This:     my_function(a, 3, "Alakazam")
  Becomes:  (my_function a 3 "Alakazam")

  The reason for this is because Lisp-style languages are very easy to parse and
  write syntax-highlighters for.

  We also provide standard Lisp syntax for comments:
  - block comments between: #| and its reverse
  - line comments following: ;;

  Unlike standard lisp, a single ; does not denote a command, but instead the
  keycode for semicolon.

  Also, as you might have noticed, whitespace is possible anywhere.

  To check for syntax errors while editing, invoke kmonad with the -d option.
  -------------------------------------------------------------------------- |#


#| --------------------------------------------------------------------------
                         Necessary: the `defcfg` block

  There are a few bits of information that are required to be present in a
  KMonad configuration file. One of these is the existence of exactly 1 `defcfg`
  statement. This statement is used to customize various configuration settings.
  Many of these settings have default values, but a minimal definition must
  include at least an 'input' field and an 'output' field. These describe how
  KMonad captures its inputs and how it emits its outputs.

  First, let's go over the optional, non-OS specific settings. Currently there is
  only 2:

  - fallthrough: `true` or `false`, defaults to `false`

    KMonad catches input events and tries to match them to various handlers. If
    it cannot match an event to any handler (for example, if it isn't included
    in the `defsrc` block, or if it is, but the current keymap does not map any
    buttons to it), then the event gets quietly ignored. If `fallthrough` is set
    to `true`, any unhandled events simply get reemitted.

  - allow-cmd: `true` or `false`, defaults to `false`

    If this is set to `false`, any action that runs a shell-command will simply
    log to `stdout` without ever running (log-level info). Don't ever enable
    this on a configuration that you do not trust, because:
      (cmd-button "rm -rf ~/*")
    is a thing.

  There are also some optional OS specific settings that we support:

  - `cmp-seq': KEY, defaults to `RightAlt' (Linux X11 specific)

    This sets your compose key for Unicode input. For more information, as well
    as a workaround to also make this work on windows, see the section on
    Compose-key sequences below.

  Secondly, let's go over how to specify the `input` and `output` fields of a
  `defcfg` block. This differs between OS'es, and so do the capabilities of
  these interfaces.


  -- Linux ------

  In Linux we deal with input by performing an ioctl-grab on a specific
  device-file. This allows us to hook KMonad on the input of exactly 1 keyboard,
  and allows you to run multiple instances of KMonad for different keyboards. We
  make an input using:
    (device-file "/dev/input/by-id/my-keyboard-kbd")

  NOTE: Any valid path to a device-file will work, but it is recommended to use
  the 'by-id' directory, since these names will not change if you replug the
  device.

  We deal with output by creating a 'uinput' device. This requires that the
  'uinput' kernel module is loaded. The easiest way to ensure this is by calling
  'sudo modprobe uinput'. We create a uinput device using:
    (uinput-sink "name" "optional post-init command")


  -- Windows ----

  In Windows we do not get such fine-grained control. We use a low-level
  keyboard hook to intercept all non-injected keyboard events. There is
  currently an open issue to improve the C-bindings used to capture windows
  keyevents, and if you have a better way to approach this issue, help is deeply
  appreciated. You specify a windows input using:
    (low-level-hook)

  Similarly, the output in Windows lacks the fine-grained control. We use the
  SendEvent API to emit key events directly to Windows. Since these are
  'artificial' events we won't end up catching them again by the
  `low-level-hook`. It is very likely that KMonad does not play well with other
  programs that capture keyboard input like AHK. You specify windows output using:
    (send-event-sink)


  -- Mac OS -----

  For Mac questions I suggest filing an issue and tagging @thoelze1, he wrote
  the MacOS API. However, input using:
    (iokit-name "optional product string")

  By default this should grab all keyboards, however if a product string is
  provided, KMonad will only capture those devices that match the provided
  product string. If you would like to provide a product string, you can run
  `make; ./list-keyboards' in c_src/mac to list the product strings of all
  connected keyboards.

  You initialize output on MacOS using:
    (kext)

  -------------------------------------------------------------------------- |#

(defcfg
  ;; For Linux
  input  (device-file "/dev/input/by-id/usb-04d9_daskeyboard-event-kbd")
  output (uinput-sink "My KMonad output"
    ;; To understand the importance of the following line, see the section on
    ;; Compose-key sequences at the near-bottom of this file.
    "/run/current-system/sw/bin/sleep 1 && /run/current-system/sw/bin/setxkbmap -option compose:ralt")
  cmp-seq ralt  ;; Set the compose key to `RightAlt'

  ;; For Windows
  ;; input  (low-level-hook)
  ;; output (send-event-sink)

  ;; For MacOS
  ;; input  (iokit-name "my-keyboard-product-string")
  ;; output (kext)

  ;; Comment this is you want unhandled events not to be emitted
  fallthrough true

  ;; Set this to false to disable any command-execution in KMonad
  allow-cmd true
)


#| --------------------------------------------------------------------------
                         Necessary: the `defsrc` block

  It is difficult to explain the `defsrc` block without immediately going into
  `deflayer` blocks as well. Essentially, KMonad maps input-events to various
  internal actions, many of which generate output events. The `defsrc` block
  explains the layout on which we specify our `deflayer`s down the line.

  It is important to realize that the `defsrc` block doesn't *necessarily* have
  to coincide with your actual input keyboard. You can specify a full 100%
  `defsrc` block, but only use a 40% keyboard. This will mean that every
  `deflayer` you specify will also have to match your 100% `defsrc`, and that
  your actual keyboard would be physically unable to trigger about 60% of your
  keymap, but it would be perfectly valid syntax.

  The dual of this (and more useful) is that it is also perfectly valid to only
  specify that part of your keyboard in `defsrc` that you want to remap. If you
  use a 100% keyboard, but don't want to remap the numpad at all you can simply
  leave the numpad out of your `defsrc`, and it should work just fine. In that
  particular case you probably want to set `fallthrough` to `true` in your
  `defcfg` block though.

  In the future we would like to provide support for multiple, named `defsrc`
  blocks, so that it becomes easier to specify various layers for just the
  numpad, for example, but at the moment any more or less than 1 `defsrc` block
  will result in an error.

  The layouting in the `defsrc` block is completely free, whitespace simply gets
  ignored. We strive to provide a name for every keycode that is no longer than
  4 characters, so we find that laying out your keymap in columns of 5 works out
  quite nicely (although wider columns will allow for more informative aliases,
  see below).

  Most keycodes should be obvious. If you are unsure, check
  './src/KMonad/Keyboard/Keycode.hs'. Every Keycode has a name corresponding to
  its Keycode name, but all lower-case and with the 'Key' prefix removed. There
  are also various aliases for Keycodes starting around line 350. If you are
  trying to bind a key and there is not a 4-letter alias, please file an issue,
  or better yet, a pull-request, and it will be added promptly.

  Also, you can consult './keymap/template/' for various input templates to use
  directly or to look up keycodes by position. Here we use the input-template
  for 'us_ansi_60.kbd'

  -------------------------------------------------------------------------- |#

(defsrc
  grv  1    2    3    4    5    6    7    8    9    0    -    =    bspc
  tab  q    w    e    r    t    y    u    i    o    p    [    ]    \
  caps a    s    d    f    g    h    j    k    l    ;    '    ret
  lsft z    x    c    v    b    n    m    ,    .    /    rsft
  lctl lmet lalt           spc            ralt rmet cmp  rctl
)


#| --------------------------------------------------------------------------
                        Optional : `defalias` statements

  KMonad will let you specify some very specific, crazy buttons. These
  definitions can get pretty long, though, and would make `deflayer` blocks
  nearly impossible to read. Therefore we provide the ability to alias names to
  these buttons, to keep the actual `deflayer` statements orderly.

  A `defalias` can contain any number of aliases, and it can refer backwards or
  forwards to layers without issue. The only sequencing that needs to be kept in
  mind is that a `defalias` cannot refer forward to another `defalias` that is
  not yet defined.

  Here we define a few aliases, but we will define more later. Notice that we
  try to only use 3 letter names for aliases. If that is not enough to be clear,
  consider widening all columns to 6 or 7 characters (or be content with a messy
  config).

  -------------------------------------------------------------------------- |#

(defalias
  num  (layer-toggle numbers) ;; Bind num to a button that switches to a layer
  kil  C-A-del                ;; Bind kil to a button that Ctrl-Alt-deletes
)


#| NOTE: The above code could just as easily have been written as:
(defalias num (layer-toggle numbers))
(defalias kil C-A-del)
|#


#| --------------------------------------------------------------------------
                     Necessary: at least 1 `deflayer` block

  As explained in the `defsrc` section, a `deflayer` will define a button for
  each corresponding entry in the `defsrc` definition. A `deflayer` statement
  consists of the `deflayer` keyword, followed by the name used to identify this
  layer, followed by N 'statements-that-evaluate-to-a-button', where N is
  exactly how many entries are defined in the `defsrc` statement.

  It is also important to mention that the 'keymap' in KMonad is modelled as a
  stack of layers (just like in QMK). When an event is registered we look in the
  top-most layer for a handler. If we don't find one we try the next layer, and
  then the next.

  Exactly what 'evaluates-to-a-button' will be expanded on in more detail below.
  There are very many different specialist buttons in KMonad that we will touch
  upon. However, for now, these 4 are a good place to begin:

  1. Any keycode evaluates to a button that, on press, emits the press of that
     keycode, and on release, emits the release of that keycode. Just a 'normal'
     button. The exception is '\', which gets used as an escape character. Use
     '\\' instead. Other characters that need to be escaped to match the literal
     character are '(', ')', and '_'.

  2. An @-prefixed name evaluates to an alias lookup. We named two buttons in
     the `defalias` block above, we could now refer to these buttons using
     `@num` and `@kil`. This is also why we only use alias-names no longer than
     3 characters in this tutorial. Also, note that we are already referencing
     some aliases that have not yet been defined, this is not an issue.

  3. The '_' character evaluates to transparent. I.e. no handler for that
     key-event in this layer, causing this event to be handed down the layer
     stack to perhaps be handled by the next layer.

  4. The 'XX' character evaluates to blocked. I.e. no action bound to that
     key-event in this layer, but do actually catch event, preventing any
     underlying layer from handling it.

  Finally, it is important to note that the *first* `deflayer` statement in a
  KMonad config will be the layer that is active when KMonad starts up.

  -------------------------------------------------------------------------- |#


(deflayer qwerty
  grv  1    2    3    4    5    6    7    8    9    0    -    =    bspc
  tab  q    w    e    r    t    y    u    i    o    p    [    ]    \
  caps a    s    d    f    g    h    j    k    l    ;    '    ret
  lsft z    x    c    v    b    n    m    ,    .    /    rsft
  lctl @num lalt           spc            ralt rmet @sym @tst
)


#| --------------------------------------------------------------------------
                     Optional: as many layers as you please

  We had already defined `num` as referring to a `(layer-toggle numbers)`. We
  will get into layer-manipulation soon, but first, let's just create a second
  layer that overlays a numpad under our right-hand.

  To easily specify layers it is highly recommended to create an empty
  `deflayer` statement as a comment at the top of your config, so you can simply
  copy-paste this template. There are also various empty layer templates
  available in the './keymap/template' directory.

  -------------------------------------------------------------------------- |#

(deflayer numbers
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    XX   /    7    8    9    -    _    _    _
  _    _    _    _    _    XX   *    4    5    6    +    _    _
  _    _    \(   \)   .    XX   0    1    2    3    _    _
  _    _    _              _              _    _    _    _
)


#| --------------------------------------------------------------------------
                          Optional: modded buttons

  Let's start by exploring the various special buttons that are supported by
  KMonad by looking at 'modded' buttons, that is to say, buttons that activate
  some kind of 'mod', then perform some button, and finally release that 'mod'
  again.

  We have already seen an example of this style of button, our `kil` button is
  one such button. Let's look at it in more detail:
    C-A-del

  This looks like a simple declarative statement, but it's helpful to realize
  that is simply syntactic sugar around 2 function calls. This statement is
  equivalent to:
    (around ctl (around alt del))

  This highlights a core design principle in KMonad: we try to provide very
  simple buttons, and then we provide rules and functions for combining them
  into new buttons. Although note: still very much a work in progress.

  So, looking at this statement:
    (around foo bar)

  Here, `around` is a function that takes two buttons and creates a new button.
  This new button will, on a press, first press foo, then press bar, and on a
  release first release bar, and then foo. Once created, this new button can be
  passed to anything in KMonad that expects a button.

  We have already seen other examples of modded buttons, \(, \), *, and +. There
  are no Keycodes for these buttons in KMonad, but they are buttons. They simply
  evaluate to `(around lsft x)`. All shifted numbers have their corresponding
  characters, the same is true for all capitals, and < > : ~ " | { } \_ + and ?.

  To wrap up 'modded-buttons', let's look back at C-A-del. We have 8 variants:
  C- : (around lctl X)
  A- : (around lalt X)
  M- : (around lmet X)
  S- : (around lsft X)

  Then RC-, RA-, RM-, and RS- behave exactly the same, except using the
  right-modifier.

  These can be combined however you please:
    C-A-M-S-x          ;; Perfectly valid
    C-%                ;; Perfectly valid: same as C-S-5
    C-RC-RA-A-M-S-RS-m ;; Sure, but why would you?

  Also, note that although we provide special syntax for certain modifiers,
  these buttons are in no way 'special' in KMonad. There is no concept of 'modifier'.
    (around a (around b c)) ;; Perfectly valid

  -------------------------------------------------------------------------- |#

(defalias

  ;; Something useful
  cpy C-c
  pst C-v
  cut C-x

  ;; Something silly
  md1 (around a (around b c))    ;; abc
  md2 (around a (around lsft b)) ;; aB
  md3 C-A-M-S-l
  md4 (around % b)               ;; BEWARE: %B, not %b, do you see why?
)

;; Now we define the 'tst' button as opening and closing a bunch of layers at
;; the same time. If you understand why this works, you're starting to grok
;; KMonad.
;;
;; Explanation: we define a bunch of testing-layers with buttons to illustrate
;; the various options in KMonad. Each of these layers makes sure to have its
;; buttons not overlap with the buttons from the other layers, and specifies all
;; its other buttons as transparent. When we use the nested `around` statement,
;; whenever we push the button linked to '@tst' (check `qwerty` layer, we bind
;; it to `rctl`), any button we press when holding `rctl` will be pressed in the
;; context of those 4 layers overlayed on the stack. When we release `rctl`, all
;; these layers will be popped again.
(defalias tst (around (layer-toggle macro-test)
                (around (layer-toggle layer-test)
                  (around (layer-toggle around-next-test)
                    (around (layer-toggle command-test)
                            (layer-toggle modded-test))))))

(deflayer modded-test
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    @md4 _    _    _    _    _    _    _    _    _    _    _
  _    _    @md1 @md2 @md3 _    _    _    _    _    _    _    _
  _    _    @cut @cpy @pst _    _    _    _    _    _    _
  _    _    _              _              _    _    _    _
)

#| --------------------------------------------------------------------------
                              Optional: tap-macros

  Let's look at a button we haven't seen yet, tap-macros.

  `tap-macro` is a function that takes an arbitrary number of buttons and
  returns a new button. When this new button is pressed it rapidly taps all its
  stored buttons in quick succesion except for its last button, which it only
  presses. This last button gets released when the `tap-macro` gets released.

  There are two ways to define a `tap-macro`, using the `tap-macro` function
  directly, or through the #() syntactic sugar. Both evaluate to exactly the
  same button.

    (tap-macro K M o n a d)
    #(K M o n a d)

  If you are going to use a `tap-macro` to perform a sequence of actions inside
  some program you probably want to include short pauses between inputs to give
  the program time to register all the key-presses. Therefore we also provide
  the 'pause' function, which simply pauses processing for a certain amount of
  milliseconds. Pauses can be created like this:
    (pause 20)
    P20

  WARNING: DO NOT STORE YOUR PASSWORDS IN PLAIN TEXT OR IN YOUR KEYBOARD

  I know it might be tempting to store your password as a macro, but there are 2
  huge risks:
  1. You accidentally leak your config and expose your password
  2. Anyone who knows about the button can get clear-text representation of your
  password with any text editor, shell, or text-input field.

  Support for triggering shell commands directly from KMonad is described in the
  command buttons section below.

  This concludes this public service announcement.

  -------------------------------------------------------------------------- |#

(defalias
  mc1 #(K M o n a d)
  mc2 #(C-c P50 A-tab P50 C-v) ;; Careful, this might do something
  mc3 #(P200 h P150 4 P100 > < P50 > < P20 0 r z 1 ! 1 ! !)
  mc4 (tap-macro a (pause 50) @md2 (pause 50) c)
  mc5 #(@mc3 spc @mc3 spc @mc3)
)

(deflayer macro-test
  _    @mc1 @mc2 @mc3 @mc4 @mc5 _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _              _              _    _    _    _
)


#| --------------------------------------------------------------------------
                          Optional: layer manipulation

  You have already seen the basics of layer-manipulation. The `layer-toggle`
  button. This button adds a layer to the top of KMonad's layer stack when
  pressed, and removes it again when released. There are a number of other ways
  to manipulate the layer stack, some safer than others. Let's go through all of
  them from safest to least safe:

  `layer-toggle` works as described before, 2 things to note:
  1. If you are confused or worried about pressing a key, changing layers, and
     then releasing a key and this causing issues: don't be. KMonad handles
     presses and releases in very different ways. Presses get passed directly to
     the stacked keymap as previously described. When a KMonad button has its
     press-action triggered, it then registers a callback that will catch its
     own release before we ever touch the keymap. This guarantees that the
     button triggered by the press of X *will be* the button whose release is
     triggered by the release of X (the release of X might trigger other things
     as well, but that is besides the point.)
  2. If `layer-toggle` can only ever add and then necessarily remove 1 layer
     from the stack, then it will never cause a permanent change, and is
     perfectly safe.

  `layer-delay`, once pressed, temporarily switches to some layer for some
  milliseconds. Just like `layer-toggle` this will never permanently mess-up the
  layer stack. This button was initially implemented to provide some
  'leader-key' style behavior. Although I think in the future better solutions
  will be available. For now this will temporarily add a layer to the top of the
  stack:
    (layer-delay 500 my-layer)

  `layer-next`, once pressed, primes KMonad to handle the next press from some
  arbitrary layer. This aims to fill the same usecase as `layer-delay`: the
  beginnings of 'leader-key' style behavior. I think this whole button will get
  deleted soon, because the more general `around-next` now exists (see below)
  and this is nothing more than:
    (around-next (layer-toggle layer-name) some-button)
  Until then though, use `layer-next` like this:
    (layer-next layer-name)

  `layer-switch`: change the base-layer of KMonad. As described at the top of
  this document, the first `deflayer` statement is the layer that is active when
  KMonad starts. Since `layer-toggle` can only ever add on and remove from the
  top of that, it can never change the base-layer. The following button will
  unregister the bottom-most layer of the keymap, and replace it with another
  layer.
    (layer-switch my-layer)

  This is where things start getting potentially dangerous (i.e. get KMonad into
  an unusuable state until a restart has occured). It is perfectly possible to
  switch into a layer that you can never get out of. Or worse, you could
  theoretically have a layer full of only `XX`s and switch into that, rendering
  your keyboard unuseable until you somehow manage to kill KMonad (without using
  your keyboard).

  However, when handled well, `layer-switch` is very useful, letting you switch
  between 'modes' for your keyboard. I have a tiny keyboard with a weird keymap,
  but I switch into a simple 'qwerty' keymap shifted 1 button to the right for
  gaming. Just make sure that any 'mode' you switch into has a button that
  allows you to switch back out of the 'mode' (or content yourself restarting
  KMonad somehow).

  `layer-add` and `layer-rem`. This is where you can very quickly cause yourself
  a big headache. Originally I didn't expose these operations, but someone
  wanted to use them, and I am not one to deny someone else a chainsaw. As the
  names might give away:
    (layer-add name) ;; Add a layer to the top of the stack
    (layer-rem name) ;; Remove a layer by name (noop if no such layer)

  To use `layer-add` and `layer-rem` well, you should take a moment to think
  about how to create a layout that will prevent you from getting into
  situations where you enter a key-configuration you cannot get out of again.
  These two operations together, however, are very useful for activating a
  permanent overlay for a while. This technique is illustrated in the tap-hold
  overlay a bit further down.


  -------------------------------------------------------------------------- |#

(defalias

  yah (layer-toggle asking-for-trouble) ;; Completely safe
  nah (layer-add asking-for-trouble)    ;; Completely unsafe

  ld1 (layer-delay 500 numbers) ;; One way to get a leader-key
  ld2 (layer-next numbers)      ;; Another way to get a leader key

  ;; NOTE, this is safe because both `qwerty` and `colemak` contain the `@tst`
  ;; button which will get us to the `layer-test` layer, which itself contains
  ;; both `@qwe` and `@col`.
  qwe (layer-switch qwerty) ;; Set qwerty as the base layer
  col (layer-switch colemak) ;; Set colemak as the base layer
)
(deflayer layer-test
  @qwe _    _    _    _    _    _    _    _    _    _    @add _    @nah
  @col _    _    _    _    _    _    _    _    _    _    _    _    @yah
  _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    @ld1 @ld2 _
  _    _    _              _              _    _    _    _
)

;; Exactly like qwerty, but with the letters switched around
(deflayer colemak
  grv  1    2    3    4    5    6    7    8    9    0    -    =    bspc
  tab  q    w    f    p    g    j    l    u    y    ;    [    ]    \
  @xcp a    r    s    t    d    h    n    e    i    o    '    ret
  lsft z    x    c    v    b    k    m    ,    .    /    rsft
  lctl @num lalt           spc            ralt rmet @sym @tst
)

(defalias lol #(: - D))

;; Contrived example
(deflayer asking-for-trouble
  @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol
  @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol
  @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol
  @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol @lol
  @lol @lol @lol           @lol           @lol @lol @lol @lol
)

;; One way to safely use layer-add and layer-rem: the button bound to layer-add
;; is the same button bound to layer-rem in the layer that `add` adds to the
;; stack. I.e., it becomes impossible to add or remove multiple copies of a
;; layer.
(defalias
  add (layer-add multi-overlay) ;; multi-overlay is defined in the next
  rem (layer-rem multi-overlay) ;; section below this
  )

#| --------------------------------------------------------------------------
                          Optional: Multi-use buttons

  Perhaps one of the most useful features of KMonad, where a lot of work has
  gone into, but also an area with many buttons that are ever so slightly
  different. The naming and structuring of these buttons might change sometime
  soon, but for now, this is what there is.

  For the next section being able to talk about examples is going to be handy,
  so consider the following scenario and mini-language that will be the same
  between scenarios.
    - We have some button `foo` that will be different between scenarios
    - `foo` is bound to 'Esc' on the input keyboard
    - the letters a s d f are bound to themselves
    - Px  signifies the press of button x on the keyboard
    - Rx  signifies the release of said button
    - Tx  signifies the sequential and near instantaneous press and release of x
    - 100 signifies 100ms pass

  So for example:
    Tesc Ta:
      tap of 'Esc' (triggering `foo`), tap of 'a' triggering `a`
    Pesc 100 Ta Tb Resc:
      press of 'Esc', 100ms pause, tap of 'a', tap of 'b', release of 'Esc'

  The `tap-next` button takes 2 buttons, one for tapping, one for holding, and
  combines them into a single button. When pressed, if the next event is its own
  release, we tap the 'tapping' button. In all other cases we first press the
  'holding' button then we handle the event. Then when the `tap-next` gets
  released, we release the 'holding' button.

  So, using our mini-language, we set foo to:
    (tap-next x lsft)
  Then:
    Tesc            -> x
    Tesc Ta         -> xa
    Pesc Ta Resc    -> A
    Pesc Ta Tr Resc -> AR

  The `tap-hold` button is very similar to `tap-next` (a theme, trust me). The
  difference lies in how the decision is made whether to tap or hold. A
  `tap-hold` waits for a particular timeout, if the `tap-hold` is released
  anywhere before that moment we execute a tap immediately. If the timeout
  occurs and the `tap-hold` is still held, we switch to holding mode.

  The additional feature of a `tap-hold` is that it pauses event-processing
  until it makes its decision and then rolls back processing when the decision
  has been made.

  So, again with the mini-language, we set foo to:
    (tap-hold 200 x lsft) ;; Like tap-next, but with a 200ms timeout
  Then:
    Tesc            -> x
    Tesc Ta         -> xa
    Pesc 300 a      -> A (the moment you press a)
    Pesc a 300      -> A (after 200 ms)
    Pesc a 100 Resc -> xa (both happening immediately on Resc)

  The `tap-hold-next` button is a combination of the previous 2. Essentially,
  think of it as a `tap-next` button, but it also switches to held after a
  period of time. This is useful, because if you have a (tap-next ret ctl) for
  example, and you press it thinking you want to press C-v, but then you change
  your mind, you now cannot release the button without triggering a 'ret', that
  you then have to backspace. With the `tap-hold-next` button, you simply
  outwait the delay, and you're good. I see no benefit of `tap-next` over
  `tap-hold-next` with a decent timeout value.

  The `tap-next-release` is like `tap-next`, except it decides whether to tap or
  hold based on the next release of a key that was *not* pressed before us. This
  also performs rollback like `tap-hold`.So, using the minilanguage and foo as:
    (tap-next-release x lsft)
  Then:
    Tesc Ta         -> xa
    Pa Pesc Ra Resc -> ax (because 'a' was already pressed when we started, so
                           foo decides it is tapping)
    Pesc Ta Resc    -> A (because a was pressed *and* released after we started,
                          so foo decides it is holding)

  These increasingly stranger buttons are, I think, coming from the stubborn
  drive of some of my more eccentric (and I mean that in the most positive way)
  users to make typing with modifiers on the home-row more comfortable.
  Especially layouts that encourage a lot of rolling motions are nicer to use
  with the `release` style buttons.

  The `tap-hold-next-release` (notice a trend?) is just like `tap-next-release`,
  but it comes with an additional timeout that, just like `tap-hold-next` will
  jump into holding-mode after a timeout.

  I honestly think that `tap-hold-next-release`, although it seems the most
  complicated, probably is the most comfortable to use. But I've put all of them
  in a testing layer down below, so give them a go and see what is nice.

  -------------------------------------------------------------------------- |#


(defalias
  xtn (tap-next x lsft)         ;; Shift that does 'x' on tap
  xth (tap-hold 400 x lsft)     ;; Long delay for easier testing
  thn (tap-hold-next 400 x lsft)
  tnr (tap-next-release x lsft)
  tnh (tap-hold-next-release 2000 x lsft)

  ;; Used it the colemak layer
  xcp (tap-hold-next 400 esc ctl)
)

;; Some of the buttons used here are defined in the next section
(deflayer multi-overlay
  @mt  _    _    _    _    _    _    _    _    _    _    _    @rem _
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  @thn _    _    _    _    _    _    _    _    _    _    _    _
  @xtn _    _    _    _    _    _    _    _    _    _    @xth
  @tnr _    _              _              _    _    _    @tnh
)


#| --------------------------------------------------------------------------
                              Optional: Multi-tap

  Besides the tap-hold style buttons there is another multi-use button (with.
  only 1 variant, at the moment). The `multi-tap`.

  A `multi-tap` codes for different buttons depending on how often it is tapped.
  It is defined by a series of delays and buttons, followed by a last button
  without delay. As long as you tap the `multi-tap` within the delay specified,
  it will jump to the next button. Once the delay is exceeded the selected
  button is pressed. If the last button in the list is reached, it is
  immediately pressed.

  Note that you can actually hold the button, so in the below example, going:
  tap-tap-hold (wait 300ms) will get you a pressed c, until you release again.

  -------------------------------------------------------------------------- |#

(defalias
  mt  (multi-tap 300 a 300 b 300 c 300 d e))


#| --------------------------------------------------------------------------
                              Optional: Around-next

  The `around-next` function creates a button that primes KMonad to perform the
  next button-press inside some context. This could be the context of 'having
  Shift pressed' or 'being inside some layer' or, less usefully, 'having d
  pressed'. It is a more general and powerful version of `layer-next`.

  I think expansion of this button-style is probably the future of leader-key,
  hydra-style functionality support in KMonad.

  -------------------------------------------------------------------------- |#

(defalias
  ns  (around-next sft)  ;; Shift the next press
  nnm (around-next @num) ;; Perform next press in numbers layer
  nd  (around-next d)    ;; Silly, but possible

)

(deflayer around-next-test
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  @nd  _    _    _    _    _    _    _    _    _    _    _    _
  @nnm _    _    _    _    _    _    _    _    _    _    _
  @ns  _    _              _              _    _    _    _
)

#| --------------------------------------------------------------------------
                        Optional: Compose-key sequences

  Compose-key sequences are series of button-presses that your operating system
  will interpret as the insertion of a special character, like accented
  characters, or various special-languages. In that sense, they are just
  syntactic sugar for keyboard macros.

  To get this to work on Linux you will need to set your compose-key with a tool
  like `setxkbmap', as well as tell kmonad that information. See the `defcfg'
  block at the top of this file for a working example. Note that you need to
  wait ever so slightly for the keyboard to register with linux before the
  command gets executed, that's why the `sleep 1`. Also, note that all the
  `/run/current-system' stuff is because the author uses NixOS. Just find a
  shell-command that will:

    1. Sleep a moment
    2. Set the compose-key to your desired key

  Please be aware that what `setxkbmap' calls the `menu' key is not actually the
  `menu' key! If you want to use the often suggested

      setxkbmap -option compose:menu

  you will have to set your compose key within kmonad to `compose' and not
  `menu'.

  After this, this should work out of the box under Linux. Windows does not
  recognize the same compose-key sequences, but WinCompose will make most of the
  sequences line up with KMonad: http://wincompose.info/
  This has not in any way been tested on Mac.

  In addition to hard-coded symbols, we also provide 'uncompleted' macros. Since
  a compose-key sequence is literally just a series of keystrokes, we can omit
  the last one, and enter the sequence for 'add an umlaut' and let the user then
  press some letter to add this umlaut to. These are created using the `+"`
  syntax.

  -------------------------------------------------------------------------- |#

(defalias
  sym (layer-toggle symbols)

)

(deflayer symbols
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  _    ä    é    ©    _    _    _    _    _    _    _    _    _    _
  _    +'   +~   +`   +^   _    _    _    _    _    _    _    _
  _    +"   _    _    _    _    _    _    _    _    _    _
  _    _    _              _              _    _    _    _)


#| --------------------------------------------------------------------------
                        Optional: Command buttons

  Currently we also provide the ability to launch arbitrary shell-commands from
  inside kmonad. These commands are simply handed off to the command-shell
  without any further checking or waiting.

  NOTE: currently only tested on Linux, but should work on any platform, as long
  as the command is valid for that platform.

  BEWARE: never run anyone's configuration without looking at it. You wouldn't
  want to push:
    (cmd-button "rm -rf ~/*") ;; Delete all this user's data


  -------------------------------------------------------------------------- |#

(defalias
  dat (cmd-button "date >> /tmp/kmonad_example.txt")   ;; Append date to tmpfile
  pth (cmd-button "echo $PATH > /tmp/kmonad_path.txt") ;; Write out PATH
)

(deflayer command-test
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    @dat @pth _
  _    _    _              _              _    _    _    _
)