Some readme fixes

MACRO_DOCS.md

@@ -511,10 +511,11 @@ For the purpose of toggling functionality on and off, and for global constants m
 
 - `set stickyMods {0|never|smart|always|1}` globally turns on or off sticky modifiers. This affects only standard scancode actions. Macro actions (both gui and command ones) are always nonsticky, unless `sticky` flag is included in `tapKey|holdKey|pressKey` commands. Default value is `smart`, which is the official behaviour - i.e., `<alt/ctrl/gui> + <tab/arrows>` are sticky. Furthermore `0 == never` and `1 == always`.
 - `set compensateDiagonalSpeed {0|1}` will divide diagonal mouse speed by sqrt(2) if enabled.
-- `set chording {0|1}` If enabled, keyboard will delay *all* actions by 50ms. If another key is pressed during this time, pending key actions will be sorted according to their type:
+- `set chording {0|1}` If enabled, keyboard will delay *all* key actions by 50ms. If another key is pressed during this time, pending key actions will be sorted according to their type:
   1) Keymap/layer switches
   2) Macros
   3) Keystrokes and mouse actions
+  This allows the user to trigger chorded shortcuts in arbitrary ordrer (all at the "same" time).
 - `set debounceDelay <time in ms, at most 250>` prevents key state from changing for some time after every state change. This is needed because contacts of mechanical switches can bounce after contact and therefore change state multiple times in span of a few milliseconds. Official firmware debounce time is 50 ms for both press and release. Recommended value is 10-50, default is 50.
 - `set keystrokeDelay <time in ms, at most 65535>` allows slowing down keyboard output. This is handy for lousily written RDP clients and other software which just scans keys once a while and processes them in wrong order if multiple keys have been pressed inbetween. In more detail, this setting adds a delay whenever a basic usb report is sent. During this delay, key matrix is still scanned and keys are debounced, but instead of activating, the keys are added into a queue to be replayed later. Recommended value is 10 if you have issues with RDP missing modifier keys, 0 otherwise.
 - `set mouseKeys.{move|scroll}.{...} NUMBER` please refer to Agent for more details
@@ -523,12 +524,31 @@ For the purpose of toggling functionality on and off, and for global constants m
   - `deceleratedSpeed` - speed as affected by deceleration modifier
   - `acceleratedSpeed` - speed as affected by acceleration modifier
   - `axisSkew`
-- `set module.MODULEID.{baseSpeed|speed|acceleration}` modifies speed characteristics of right side modules. Simplified formula is `modifiedSpeed(normalizedSpeed) = baseSpeed*s + speed*(normalizedSpeed^acceleration)` where `normalizedSpeed = actualSpeed / midSpeed`. Therefore `appliedDistance(distance d, time t) = d*(baseSpeed*((d/t)/midSpeed) + speed*(((d/t)/midSpeed)^acceleration))`. (`d/t` is actual speed in px/s, `(d/t)/midSpeed` is normalizedSpeed which acts as base for the exponent)
+- `set module.MODULEID.{baseSpeed|speed|acceleration}` modifies speed characteristics of right side modules. Simplified formula is `speedMultiplier(normalizedSpeed) = baseSpeed + speed*(normalizedSpeed^acceleration)` where `normalizedSpeed = actualSpeed / midSpeed`. Therefore `appliedDistance(distance d, time t) = d*(baseSpeed*((d/t)/midSpeed) + d*speed*(((d/t)/midSpeed)^acceleration))`. (`d/t` is actual speed in px/s, `(d/t)/midSpeed` is normalizedSpeed which acts as base for the exponent)
   - `baseSpeed` is base speed multiplier which is not affected by acceleration. I.e., if `speed = 0`, then traveled distance is `reportedDistance*baseSpeed`
   - `speed` multiplies effect of acceleration expression. I.e., simply multiplies the reported distance when the actual speed equals `midSpeed`.
   - `acceleration` is exponent applied to the speed normalized w.r.t midSpeed. I.e., acceleration expression of the formula is `speed*(reportedSpeed/midSpeed)^(acceleration)`. I.e., no acceleration = 0, reasonable (square root) acceleration = 0.5. Highest recommended value is 1.0.
-  - `midSpeed` represents "middle" speed, where the user can easily imagine behaviour of the device (currently fixed 3000 px/s) and henceforth easily set the coefficient. At this speed, `modifiedSpeed = (baseSpeed + speed)*reportedSpeed` 
-  - Recommended settings - e.g. `0.0 1.0 0.5 3000` (square root multiplier, starting at 0 speed - allowing for very precise movement at low speed) or `0.5 0.5 1.0 3000` (linear speedup starting at 0.5 - providing more uniform acceleration).
+  - `midSpeed` represents "middle" speed, where the user can easily imagine behaviour of the device (currently fixed 3000 px/s) and henceforth easily set the coefficient. At this speed, acceleration formula yields `1.0`, i.e., `speedModifier = (baseSpeed + speed)`.
+  - (Mostly) reasonable examples (`baseSpeed speed acceleration baseSpeed`):
+    - `0.0 1.0 0.0 3000` (no acceleration)
+      - speed multiplier is always 1x at all speeds
+    - `0.0 1.0 0.5 3000` (square root multiplier)
+      - starts at 0x speed multiplier - allowing for very precise movement at low speed)
+      - at 3000 px/s, yields cursor speed equal to actually picked up movement
+      - at 12000 px/s, cursor speed is going to be twice the movement (because `sqrt(4) = 2`)
+    - `0.5 0.5 1.0 3000` (linear speedup starting at 0.5)
+      - starts at 0.5x speed multipier - meaning that resulting cursor speed is half the picked up movement at low speeds
+      - at 3000 px/s, speed multiplier is 1x
+      - at 12000 px/s, speed multiplier is 2.5x
+      - (notice that linear acceleration actually means quadratic overall curve)
+    - `1.0 1.0 1.0 3000`
+      - same as before, but resulting cursor speed is double. I.e., 1x at 0 speed, 2x at 3000 px/s, 5x at 12000 px/s
+    - `0.0 1.0 1.0 3000` (linear speedup starting at 0)
+      - again very precise at low speed
+      - at 3000 px/s, speed multiplier is 1x
+      - at 6000 px/s, speed multiplier is 4x
+      - not recommended - the curve will behave in very non-linear fashion.
+
 
 ### Argument parsing rules: