Branch point for 2019 Nov 30 Breaking Change.

.github/ISSUE_TEMPLATE/blank.md

@@ -1,11 +1,5 @@
 ---
 name: Blank issue
-about: If you're 100% sure that you don't need one of the other issue templates, use
-  this one instead.
-title: ''
-labels: help wanted, question
-assignees: ''
+about: If you're 100% sure that you don't need one of the other issue templates, use this one instead. 
 
 ---
-
-

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,12 +1,7 @@
 ---
 name: Bug report
-about: Create a report to help us improve QMK Firmware.
-title: "[Bug] "
-labels: bug, help wanted
-assignees: ''
-
+about: Create a report to help us improve the QMK Firmware
 ---
-
 <!-- Provide a general summary of the bug in the title above. -->
 
 <!--- This template is entirely optional and can be removed, but is here to help both you and us. -->

.github/ISSUE_TEMPLATE/config.yml

@@ -1,8 +0,0 @@
-blank_issues_enabled: false
-contact_links:
-  - name: QMK Discord
-    url: https://discord.gg/Uq7gcHh
-    about: Ask questions, discuss issues and features. Chill.
-  - name: OLKB Subreddit
-    url: https://www.reddit.com/r/olkb
-    about: All things OLKB and QMK.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,12 +1,7 @@
 ---
 name: Feature request
-about: Suggest a new feature or changes to existing features.
-title: "[Feature Request] "
-labels: enhancement, help wanted
-assignees: ''
-
+about: Suggest a new feature or changes to existing features 
 ---
-
 <!--- Provide a general summary of the changes you want in the title above. -->
 
 <!--- This template is entirely optional and can be removed, but is here to help both you and us. -->

.github/ISSUE_TEMPLATE/other_issues.md

@@ -1,12 +1,7 @@
 ---
 name: Other issues
-about: Anything else that doesn't fall into the above categories.
-title: ''
-labels: help wanted, question
-assignees: ''
-
+about: Anything else that doesn't fall into the above categories. 
 ---
-
 <!--- Provide a general summary of the changes you want in the title above. -->
 
 <!--- Anything on lines wrapped in comments like these will not show up in the final text. -->

.github/stale.yml

@@ -1,58 +0,0 @@
-# Configuration for probot-stale - https://github.com/probot/stale
-
-# General configuration
-
-# Pull request specific configuration
-pulls:
-  staleLabel: awaiting changes
-  # Number of days of inactivity before an Issue or Pull Request becomes stale
-  daysUntilStale: 45
-  # Number of days of inactivity before a stale Issue or Pull Request is closed.
-  # Set to false to disable. If disabled, issues still need to be closed manually, but will remain marked as stale.
-  daysUntilClose: 30
-  # Comment to post when marking as stale. Set to `false` to disable
-  markComment: >
-    Thank you for your contribution!
-
-    This pull request has been automatically marked as stale because it has not had
-    activity in the last 45 days. It will be closed in 30 days if no further activity occurs.
-    Please feel free to give a status update now, or re-open when it's ready.
-    
-    For maintainers: Please label with `awaiting review`, `breaking_change`, `in progress`, or `on hold` to prevent 
-    the issue from being re-flagged.
-  # Comment to post when closing a stale Issue or Pull Request.
-  closeComment: >
-    Thank you for your contribution!
-
-    This pull request has been automatically closed because it has not had activity in the last 30 days.
-    Please feel free to give a status update now, ping for review, or re-open when it's ready.
-  # Limit the number of actions per hour, from 1-30. Default is 30
-  limitPerRun: 30
-  exemptLabels:
-    - awaiting review
-    - breaking_change
-    - in progress
-    - on hold
-
-# Issue specific configuration
-issues:
-  staleLabel: stale
-  limitPerRun: 10
-  daysUntilStale: 90
-  daysUntilClose: 30
-  markComment: >
-    This issue has been automatically marked as stale because it has not had activity in the
-    last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity
-    occurs.
-    
-    For maintainers: Please label with `bug`, `in progress`, `on hold`, `discussion` or `to do` to prevent 
-    the issue from being re-flagged.
-  closeComment: >
-    This issue has been automatically closed because it has not had activity in the last 30 days.
-    If this issue is still valid, re-open the issue and let us know.
-  exemptLabels:
-    - bug
-    - in progress
-    - on hold
-    - discussion
-    - to do

.github/workflows/cli.yml

@@ -1,28 +0,0 @@
-name: CLI CI
-
-on:
-  push:
-    branches:
-    - master
-    - future
-  pull_request:
-    paths:
-    - 'lib/python/**'
-    - 'bin/qmk'
-    - 'requirements.txt'
-    - '.github/workflows/cli.yml'
-
-jobs:
-  test:
-    runs-on: ubuntu-latest
-
-    container: qmkfm/base_container
-
-    steps:
-    - uses: actions/checkout@v1
-      with:
-        submodules: recursive
-    - name: Install dependencies
-      run: pip3 install -r requirements.txt
-    - name: Run tests
-      run: bin/qmk pytest

.gitignore

@@ -25,7 +25,7 @@ quantum/version.h
 CMakeLists.txt
 cmake-build-debug
 doxygen/
-.DS_Store
+.DS_STORE
 /util/wsl_downloaded
 /util/win_downloaded
 /keyboards/*/Makefile
@@ -60,8 +60,11 @@ util/Win_Check_Output.txt
 
 # ignore image files
 *.png
-*.gif
 *.jpg
+*.gif
+
+# Do not ignore MiniDox left/right hand eeprom files
+!keyboards/minidox/*.eep
 
 # things travis sees
 secrets.tar

.travis.yml

@@ -1,5 +1,6 @@
 os: linux
 dist: trusty
+sudo: required
 group: edge
 language: c
 branches:
@@ -12,26 +13,20 @@ env:
   - MAKEFLAGS="-j3 --output-sync"
 services:
   - docker
+install:
+  - npm install -g moxygen
+script:
+  - git rev-parse --short HEAD
+  - bash util/travis_test.sh
+  - bash util/travis_build.sh
+  - bash util/travis_docs.sh
 addons:
   apt:
-    sources:
-      - ubuntu-toolchain-r-test
-      - llvm-toolchain-trusty-7
     packages:
     - pandoc
     - diffutils
     - dos2unix
     - doxygen
-    - clang-format-7
-    - libstdc++-7-dev
-install:
-  - npm install -g moxygen
-script:
-  - git rev-parse --short HEAD
-  - git diff --name-only HEAD $TRAVIS_BRANCH
-  - bash util/travis_test.sh
-  - bash util/travis_build.sh
-  - bash util/travis_docs.sh
 after_script:
   bash util/travis_compiled_push.sh
 notifications:

Makefile

@@ -272,14 +272,12 @@ define PARSE_RULE
     # If the rule starts with all, then continue the parsing from
     # PARSE_ALL_KEYBOARDS
     ifeq ($$(call COMPARE_AND_REMOVE_FROM_RULE,all),true)
-        KEYBOARD_RULE=all
         $$(eval $$(call PARSE_ALL_KEYBOARDS))
     else ifeq ($$(call COMPARE_AND_REMOVE_FROM_RULE,test),true)
         $$(eval $$(call PARSE_TEST))
     # If the rule starts with the name of a known keyboard, then continue
     # the parsing from PARSE_KEYBOARD
     else ifeq ($$(call TRY_TO_MATCH_RULE_FROM_LIST,$$(KEYBOARDS)),true)
-        KEYBOARD_RULE=$$(MATCHED_ITEM)
         $$(eval $$(call PARSE_KEYBOARD,$$(MATCHED_ITEM)))
     # Otherwise use the KEYBOARD variable, which is determined either by
     # the current directory you run make from, or passed in as an argument
@@ -382,9 +380,6 @@ define PARSE_KEYBOARD
     # Otherwise try to match the keymap from the current folder, or arguments to the make command
     else ifneq ($$(KEYMAP),)
         $$(eval $$(call PARSE_KEYMAP,$$(KEYMAP)))
-    # Otherwise if we are running make all:<user> just skip
-    else ifeq ($$(KEYBOARD_RULE),all)
-        # $$(info Skipping: No user keymap for $$(CURRENT_KB))
     # Otherwise, make all keymaps, again this is consistent with how it works without
     # any arguments
     else
@@ -563,10 +558,10 @@ endef
 	if ! python3 --version 1> /dev/null 2>&1; then printf "$(MSG_PYTHON_MISSING)"; fi
 	# Check if the submodules are dirty, and display a warning if they are
 ifndef SKIP_GIT
-	if [ ! -e lib/chibios ]; then git submodule sync lib/chibios && git submodule update --depth 50 --init lib/chibios; fi
-	if [ ! -e lib/chibios-contrib ]; then git submodule sync lib/chibios-contrib && git submodule update --depth 50 --init lib/chibios-contrib; fi
-	if [ ! -e lib/ugfx ]; then git submodule sync lib/ugfx && git submodule update --depth 50 --init lib/ugfx; fi
-	if [ ! -e lib/lufa ]; then git submodule sync lib/lufa && git submodule update --depth 50 --init lib/lufa; fi
+	if [ ! -e lib/chibios ]; then git submodule sync lib/chibios && git submodule update --depth 1 --init lib/chibios; fi
+	if [ ! -e lib/chibios-contrib ]; then git submodule sync lib/chibios-contrib && git submodule update --depth 1 --init lib/chibios-contrib; fi
+	if [ ! -e lib/ugfx ]; then git submodule sync lib/ugfx && git submodule update --depth 1 --init lib/ugfx; fi
+	if [ ! -e lib/lufa ]; then git submodule sync lib/lufa && git submodule update --depth 1 --init lib/lufa; fi
 	git submodule status --recursive 2>/dev/null | \
 	while IFS= read -r x; do \
 		case "$$x" in \

bin/qmk

@@ -4,8 +4,10 @@
 import os
 import subprocess
 import sys
-from importlib.util import find_spec
+from glob import glob
 from time import strftime
+from importlib import import_module
+from importlib.util import find_spec
 
 # Add the QMK python libs to our path
 script_dir = os.path.dirname(os.path.realpath(__file__))
@@ -13,8 +15,12 @@ qmk_dir = os.path.abspath(os.path.join(script_dir, '..'))
 python_lib_dir = os.path.abspath(os.path.join(qmk_dir, 'lib', 'python'))
 sys.path.append(python_lib_dir)
 
+# Change to the root of our checkout
+os.environ['ORIG_CWD'] = os.getcwd()
+os.chdir(qmk_dir)
+
 # Make sure our modules have been setup
-with open(os.path.join(qmk_dir, 'requirements.txt'), 'r') as fd:
+with open('requirements.txt', 'r') as fd:
     for line in fd.readlines():
         line = line.strip().replace('<', '=').replace('>', '=')
 
@@ -25,64 +31,73 @@ with open(os.path.join(qmk_dir, 'requirements.txt'), 'r') as fd:
             line = line.split('#')[0]
 
         module = line.split('=')[0] if '=' in line else line
-
-        if module in ['pep8-naming']:
-            # Not every module is importable by its own name.
-            continue
-
         if not find_spec(module):
-            print('Could not find module %s!' % module)
-            print('Please run `pip3 install -r requirements.txt` to install the python dependencies.')
+            print('Your QMK build environment is not fully setup!\n')
+            print('Please run `./util/qmk_install.sh` to setup QMK.')
             exit(255)
 
 # Figure out our version
-# TODO(skullydazed/anyone): Find a method that doesn't involve git. This is slow in docker and on windows.
 command = ['git', 'describe', '--abbrev=6', '--dirty', '--always', '--tags']
-result = subprocess.run(command, universal_newlines=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+result = subprocess.run(command, universal_newlines=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 
 if result.returncode == 0:
-    os.environ['QMK_VERSION'] = result.stdout.strip()
+    os.environ['QMK_VERSION'] = 'QMK ' + result.stdout.strip()
 else:
-    os.environ['QMK_VERSION'] = 'nogit-' + strftime('%Y-%m-%d-%H:%M:%S') + '-dirty'
+    os.environ['QMK_VERSION'] = 'QMK ' + strftime('%Y-%m-%d-%H:%M:%S')
 
 # Setup the CLI
-import milc  # noqa
-
+import milc
 milc.EMOJI_LOGLEVELS['INFO'] = '{fg_blue}Ψ{style_reset_all}'
 
+# If we were invoked as `qmk <cmd>` massage sys.argv into `qmk-<cmd>`.
+# This means we can't accept arguments to the qmk script itself.
+script_name = os.path.basename(sys.argv[0])
+if script_name == 'qmk':
+    if len(sys.argv) == 1:
+        milc.cli.log.error('No subcommand specified!\n')
 
-@milc.cli.entrypoint('QMK Helper Script')
-def qmk_main(cli):
-    """The function that gets run when no subcommand is provided.
-    """
-    cli.print_help()
-
-
-def main():
-    """Setup our environment and then call the CLI entrypoint.
-    """
-    # Change to the root of our checkout
-    os.environ['ORIG_CWD'] = os.getcwd()
-    os.chdir(qmk_dir)
-
-    # Import the subcommands
-    import qmk.cli  # noqa
-
-    # Execute
-    return_code = milc.cli()
-
-    if return_code is False:
+    if len(sys.argv) == 1 or sys.argv[1] in ['-h', '--help']:
+        milc.cli.echo('usage: qmk <subcommand> [...]')
+        milc.cli.echo('\nsubcommands:')
+        subcommands = glob(os.path.join(qmk_dir, 'bin', 'qmk-*'))
+        for subcommand in sorted(subcommands):
+            subcommand = os.path.basename(subcommand).split('-', 1)[1]
+            milc.cli.echo('\t%s', subcommand)
+        milc.cli.echo('\nqmk <subcommand> --help for more information')
         exit(1)
 
-    elif return_code is not True and isinstance(return_code, int):
-        if return_code < 0 or return_code > 255:
-            milc.cli.log.error('Invalid return_code: %d', return_code)
-            exit(255)
+    if sys.argv[1] in ['-V', '--version']:
+        milc.cli.echo(os.environ['QMK_VERSION'])
+        exit(0)
 
-        exit(return_code)
+    sys.argv[0] = script_name = '-'.join((script_name, sys.argv[1]))
+    del sys.argv[1]
 
+# Look for which module to import
+if script_name == 'qmk':
+    milc.cli.print_help()
     exit(0)
+elif not script_name.startswith('qmk-'):
+    milc.cli.log.error('Invalid symlink, must start with "qmk-": %s', script_name)
+else:
+    subcommand = script_name.replace('-', '.').replace('_', '.').split('.')
+    subcommand.insert(1, 'cli')
+    subcommand = '.'.join(subcommand)
 
+    try:
+        import_module(subcommand)
+    except ModuleNotFoundError as e:
+        if e.__class__.__name__ != subcommand:
+            raise
+
+        milc.cli.log.error('Invalid subcommand! Could not import %s.', subcommand)
+        exit(1)
 
 if __name__ == '__main__':
-    main()
+    return_code = milc.cli()
+    if return_code is False:
+        exit(1)
+    elif return_code is not True and isinstance(return_code, int) and return_code < 256:
+        exit(return_code)
+    else:
+        exit(0)

bin/qmk-compile-json

@@ -0,0 +1 @@
+qmk

bin/qmk-doctor

@@ -0,0 +1 @@
+qmk

bin/qmk-hello

@@ -0,0 +1 @@
+qmk

bin/qmk-json-keymap

@@ -0,0 +1 @@
+qmk

bootloader.mk

@@ -82,13 +82,6 @@ ifeq ($(strip $(BOOTLOADER)), USBasp)
     OPT_DEFS += -DBOOTLOADER_USBASP
     BOOTLOADER_SIZE = 4096
 endif
-ifeq ($(strip $(BOOTLOADER)), lufa-ms)
-    # DO NOT USE THIS BOOTLOADER IN NEW PROJECTS!
-    # It is extremely prone to bricking, and is only included to support existing boards.
-    OPT_DEFS += -DBOOTLOADER_MS
-    BOOTLOADER_SIZE = 6144
-    FIRMWARE_FORMAT = bin
-endif
 
 ifdef BOOTLOADER_SIZE
     OPT_DEFS += -DBOOTLOADER_SIZE=$(strip $(BOOTLOADER_SIZE))

build_json.mk

@@ -22,5 +22,6 @@ else ifneq ("$(wildcard $(MAIN_KEYMAP_PATH_1)/keymap.json)","")
 endif
 
 # Generate the keymap.c
-$(KEYBOARD_OUTPUT)/src/keymap.c: $(KEYMAP_JSON)
-	bin/qmk json-keymap --quiet --output $(KEYMAP_C) $(KEYMAP_JSON)
+ifneq ("$(KEYMAP_JSON)","")
+    _ = $(shell test -e $(KEYMAP_C) || bin/qmk-json-keymap $(KEYMAP_JSON) -o $(KEYMAP_C))
+endif

docs/LANGS.md

@@ -0,0 +1,4 @@
+# Languages
+
+* [English](/)
+* [Chinese](zh/)

docs/README.md

@@ -15,7 +15,7 @@ QMK (*Quantum Mechanical Keyboard*) is an open source community that maintains Q
 
 If you plan on contributing a keymap, keyboard, or features to QMK, the easiest thing to do is [fork the repo through Github](https://github.com/qmk/qmk_firmware#fork-destination-box), and clone your repo locally to make your changes, push them, then open a [Pull Request](https://github.com/qmk/qmk_firmware/pulls) from your fork.
 
-Otherwise, you can clone it directly with `git clone https://github.com/qmk/qmk_firmware`. Do not download the zip or tar files; a git repository is required to download the submodules in order to compile.
+Otherwise, you can either download it directly ([zip](https://github.com/qmk/qmk_firmware/zipball/master), [tar](https://github.com/qmk/qmk_firmware/tarball/master)), or clone it via git (`git@github.com:qmk/qmk_firmware.git`), or https (`https://github.com/qmk/qmk_firmware.git`).
 
 ## How to Compile
 

docs/_langs.md

@@ -1,9 +0,0 @@
-- Translations
-  - [:uk: English](/)
-  - [:cn: 中文](/zh-cn/)
-  - [:es: Español](/es/)
-  - [:fr: Français](/fr-fr/)
-  - [:he: עברית](/he-il/)
-  - [:brazil: Português](/pt-br/)
-  - [:ru: Русский](/ru-ru/)
-  - [:jp: 日本語](/ja/)

docs/_summary.md

@@ -3,22 +3,17 @@
   * [Building Your First Firmware](newbs_building_firmware.md)
   * [Flashing Firmware](newbs_flashing.md)
   * [Testing and Debugging](newbs_testing_debugging.md)
-  * [Best Git Practices](newbs_git_best_practices.md)
-    * [Using Your Fork's Master](newbs_git_using_your_master_branch.md)
-    * [Resolving Merge Conflicts](newbs_git_resolving_merge_conflicts.md)
-    * [Resynchronizing a Branch](newbs_git_resynchronize_a_branch.md)
+  * [Git Best Practices](newbs_best_practices.md)
   * [Learning Resources](newbs_learn_more_resources.md)
 
 * [QMK Basics](README.md)
   * [QMK Introduction](getting_started_introduction.md)
   * [QMK CLI](cli.md)
-  * [QMK CLI Config](cli_configuration.md)
   * [Contributing to QMK](contributing.md)
   * [How to Use Github](getting_started_github.md)
   * [Getting Help](getting_started_getting_help.md)
 
 * [Breaking Changes](breaking_changes.md)
-  * [My Pull Request Was Flagged](breaking_changes_instructions.md)
   * [2019 Aug 30](ChangeLog/20190830.md)
 
 * [FAQ](faq.md)
@@ -37,7 +32,6 @@
   * [Keymap Overview](keymap.md)
 
 * [Hardware](hardware.md)
-  * [Compatible Microcontrollers](compatible_microcontrollers.md)
   * [AVR Processors](hardware_avr.md)
   * [Drivers](hardware_drivers.md)
 
@@ -54,7 +48,7 @@
   * [Useful Functions](ref_functions.md)
   * [Configurator Support](reference_configurator_support.md)
   * [info.json Format](reference_info_json.md)
-  * [Python CLI Development](cli_development.md)
+  * [Python Development](python_development.md)
 
 * [Features](features.md)
   * [Basic Keycodes](keycodes_basic.md)
@@ -102,12 +96,8 @@
   * [Hand Wiring Guide](hand_wire.md)
   * [ISP Flashing Guide](isp_flashing_guide.md)
   * [ARM Debugging Guide](arm_debugging.md)
-  * [ADC Driver](adc_driver.md)
   * [I2C Driver](i2c_driver.md)
-  * [WS2812 Driver](ws2812_driver.md)
-  * [EEPROM Driver](eeprom_driver.md)
   * [GPIO Controls](internals_gpio_control.md)
-  * [Custom Matrix](custom_matrix.md)
   * [Proton C Conversion](proton_c_conversion.md)
 
 * For a Deeper Understanding
@@ -118,7 +108,6 @@
   * [Using Eclipse with QMK](other_eclipse.md)
   * [Using VSCode with QMK](other_vscode.md)
   * [Support](support.md)
-  * [Translating the QMK Docs](translating.md)
 
 * QMK Internals (In Progress)
   * [Defines](internals_defines.md)

docs/adc_driver.md

@@ -1,50 +0,0 @@
-# ADC Driver
-
-QMK can leverage the Analog-to-Digital Converter (ADC) on supported MCUs to measure voltages on certain pins. This can be useful for implementing things such as battery level indicators for Bluetooth keyboards, or volume controls using a potentiometer, as opposed to a [rotary encoder](feature_encoders.md).
-
-This driver is currently AVR-only. The values returned are 10-bit integers (0-1023) mapped between 0V and VCC (usually 5V or 3.3V).
-
-## Usage
-
-To use this driver, add the following to your `rules.mk`:
-
-```make
-SRC += analog.c
-```
-
-Then place this include at the top of your code:
-
-```c
-#include "analog.h"
-```
-
-## Channels
-
-|Channel|AT90USB64/128|ATmega16/32U4|ATmega32A|ATmega328P|
-|-------|-------------|-------------|---------|----------|
-|0      |`F0`         |`F0`         |`A0`     |`C0`      |
-|1      |`F1`         |`F1`         |`A1`     |`C1`      |
-|2      |`F2`         |             |`A2`     |`C2`      |
-|3      |`F3`         |             |`A3`     |`C3`      |
-|4      |`F4`         |`F4`         |`A4`     |`C4`      |
-|5      |`F5`         |`F5`         |`A5`     |`C5`      |
-|6      |`F6`         |`F6`         |`A6`     |*         |
-|7      |`F7`         |`F7`         |`A7`     |*         |
-|8      |             |`D4`         |         |          |
-|9      |             |`D6`         |         |          |
-|10     |             |`D7`         |         |          |
-|11     |             |`B4`         |         |          |
-|12     |             |`B5`         |         |          |
-|13     |             |`B6`         |         |          |
-
-<sup>\* The ATmega328P possesses two extra ADC channels; however, they are not present on the DIP pinout, and are not shared with GPIO pins. You can use `adc_read()` directly to gain access to these.</sup>
-
-## Functions
-
-|Function                    |Description                                                                                                        |
-|----------------------------|-------------------------------------------------------------------------------------------------------------------|
-|`analogReference(mode)`     |Sets the analog voltage reference source. Must be one of `ADC_REF_EXTERNAL`, `ADC_REF_POWER` or `ADC_REF_INTERNAL`.|
-|`analogRead(pin)`           |Reads the value from the specified Arduino pin, eg. `4` for ADC6 on the ATmega32U4.                                |
-|`analogReadPin(pin)`        |Reads the value from the specified QMK pin, eg. `F6` for ADC6 on the ATmega32U4.                                   |
-|`pinToMux(pin)`             |Translates a given QMK pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)".   |
-|`adc_read(mux)`             |Reads the value from the ADC according to the specified mux. See your MCU's datasheet for more information.        |

docs/arm_debugging.md

@@ -1,4 +1,4 @@
-# ARM Debugging using Eclipse
+# ARM Debugging usign Eclipse
 
 This page describes how to setup debugging for ARM MCUs using an SWD adapter and open-source/free tools. In this guide we will install GNU MCU Eclipse IDE for C/C++ Developers and OpenOCD together with all the necessary dependencies.
 
@@ -6,19 +6,19 @@ This guide is catered towards advance users and assumes you can compile an ARM c
 
 ## Installing the software
 
-The main objective here is to get the MCU Eclipse IDE correctly installed on our machine. The necessary instructions are derived from [this](https://gnu-mcu-eclipse.github.io/install/) install guide.
+The main objective here is to get the MCU Eclipse IDE correcly installed on our machine. The necesarry instructions are derived from [this](https://gnu-mcu-eclipse.github.io/install/) install guide.
 
 ### The xPack Manager
 
-This tool is a software package manager and it is used to help us get the necessary dependencies.
+This tool is a software package manager and it is used to help us get the necesarry depencencies.
 
-XPM runs using Node.js so grab that from [here](https://nodejs.org/en/). After installation, open a terminal and type `npm -v`. A reply with the version number means that the installation was successful.
+XPM runs using Node.js so grab that form [here](https://nodejs.org/en/). After installation, open a terminal and type `npm -v`. A reply with the version number means that the instalation was successful.
 
-XPM installation instructions can be found [here](https://www.npmjs.com/package/xpm) and are OS specific. Entering `xpm --version` to your terminal should return the software version.
+XPM instalation instructions can be found [here](https://www.npmjs.com/package/xpm) and are OS specific. Entering `xpm --version` to your terminal should return the software version.
 
 ### The ARM Toolchain
 
-Using XPM it is very easy to install the ARM toolchain. Enter the command `xpm install --global @xpack-dev-tools/arm-none-eabi-gcc`.
+Using XPM it is very easy to install the ARM toolchain. Enter the command `xpm install --global @gnu-mcu-eclipse/arm-none-eabi-gcc`.
 
 ### Windows build tools
 
@@ -26,14 +26,14 @@ If you are using windows you need to install this!
 
 `xpm install --global @gnu-mcu-eclipse/windows-build-tools`
 
-### Programmer/Debugger Drivers
+### Programer/Debugger Drivers
 
-Now it's time to install your programmer's drivers. This tutorial was made using an ST-Link v2 which you can get from almost anywhere.
-If you have an ST-Link the drivers can be found [here](https://www.st.com/en/development-tools/stsw-link009.html) otherwise consult the manufacturer of your tool.
+Now its the time to install your programer's drivers. This tutorial was made using an ST-Link v2 which you can get from almost anywhere.
+If you have an ST-Link the drivers can be found [here](https://www.st.com/en/development-tools/stsw-link009.html) otherwise consult the manufuturer of your tool.
 
 ### OpenOCD
 
-This dependency allows SWD access from GDB and it is essential for debugging. Run `xpm install --global @xpack-dev-tools/openocd`.
+This dependency allows SWD access from GDB and it is essential for debugging. Run `xpm install --global @gnu-mcu-eclipse/openocd`.
 
 ### Java
 
@@ -45,17 +45,17 @@ Now its finally time to install the IDE. Use the Release page [here](https://git
 
 ## Configuring Eclipse
 
-Open up the Eclipse IDE we just downloaded. To import our QMK directory select File -> Import -> C/C++ -> Existing Code as Makefile Project. Select Next and use Browse to select your QMK folder. In the tool-chain list select ARM Cross GCC and select Finish.
+Open up the Eclipse IDE we just downloaded. To import our QMK directory select File -> Import -> C/C++ -> Existing code as Makefile Project. Select next and use Browse to select your QMK folder. In the tool-chain list select ARM Cross GCC and select Finish.
 
-Now you can see the QMK folder on the left hand side. Right click it and select Properties. On the left hand side, expand MCU and select ARM Toolchains Paths. Press xPack and OK. Repeat for OpenOCD Path and if you are on Windows for Build Tools Path. Select Apply and Close.
+Now you can see the QMK folder on the left hand side. Right click it and select Properties. On the left hand side, expand MCU and select ARM Toolchain Paths. Press xPack and OK. Repeat for OpenOCD Path  and if you are on windows for Build Tool Path. Select Apply and Close.
 
-Now its time to install the necessary MCU packages. Go to Packs perspective by selecting Window -> Perspective -> Open Perspective -> Other... -> Packs. Now select the yellow refresh symbol next to the Packs tab. This will take a long time as it is requesting the MCU definitions from various places. If some of the links fail you can probably select Ignore.
+Now its time to install the necessary MCU packages. Go to Packs perspective by selecting Window -> Open Perspective -> Others -> Packs. Now select the yellow refresh symbol next to the Packs tab. This will take a long time as it is requesting the MCU definitions from various places. If some of the links fail you can probably select Ignore.
 
-When this finishes you must find the MCU which we will be building/debugging for. In this example I will be using the STM32F3 series MCUs. On the left, select STMicroelectronics -> STM32F3 Series. On the middle window we can see the pack. Right click and select Install. Once that is done we can go back to the default perspective, Window -> Perspective -> Open Perspective -> Other... -> C/C++.
+When this finishes you must find the MCU which we will be building/debugging for. In this example I will be using the STM32F3 series MCUs. On the left, select STMicroelectonics -> STM32F3 Series. On the middle window we can see the pack. Right click and select Install. Once that is done we can go back to the default perspective, Window -> Open Perspective -> Others -> C/C++.
 
-We need to let eclipse know the device we intent to build QMK on. Right click on the QMK folder -> Properties -> C/C++ Build -> Settings. Select the Devices tab and under Devices select the appropriate variant of your MCU. For my example it is STM32F303CC
+We need to let eclipse know the device we intent to build QMK on. Right click on the QMK folder -> Properties -> C/C++ Build -> Settings. Select the Devices tab and under devices select the appropriate variant of your MCU. For my example it is STM32F303CC
 
-While we are here let's setup the build command as well. Select C/C++ Build and then the Behavior tab. On the Build command, replace `all` with your necessary make command. For example for a rev6 Planck with the default keymap this would be `planck/rev6:default`. Select Apply and Close.
+While we are here let's setup the build command as well. Select C/C++ Build and then the Behavior tab. On the build command, replace `all` with your necessary make command. For example for a rev6 Planck with the default keymap this would be `planck/rev6:default`. Select Apply and Close.
 
 ## Building
 
@@ -71,7 +71,7 @@ NOTE: Make sure the SWCLK and SWDIO pins are not used in the matrix of your keyb
 
 ### Configuring the Debugger
 
-Right click on your QMK folder, select Debug As -> Debug Configurations... . Here double click on GDB OpenOCD Debugging. Select the Debugger tab and enter the configuration necessary for your MCU. This might take some fiddling and Googling to find out. The default script for the STM32F3 is called `stm32f3discovery.cfg`. To let OpenOCD know, in the Config options enter `-f board/stm32f3discovery.cfg`.
+Right click on your QMK folder, select Debug As -> Debug Configuration. Here double click on GDB OpenOCD Debugging. Select the debugger tab and enter the configuration necessary for your MCU. This might take some fiddling and googleing to find out. The default script for the STM32F3 is called stm32f3discovery.cfg. To let OpenOCD know, in the Config options enter `-f board/stm32f3discovery.cfg`.
 
 NOTE: In my case this configuration script requires editing to disable the reset assertion. The locations of the scripts can be found in the actual executable field usually under the path `openocd/version/.content/scripts/board`. Here I edited `reset_config srst_only` to `reset_config none`.
 
@@ -81,7 +81,7 @@ Select Apply and Close.
 
 Reset your keyboard.
 
-Press the bug icon and if all goes well you should soon find yourself in the Debug perspective. Here the program counter will pause at the beginning of the main function and wait for you to press Play. Most of the features of all debuggers work on Arm MCUs but for exact details Google is your friend!
+Press the bug icon and if all goes well you should soon find yourself in the debug perspective. Here the program counter will pause at the beginning of the main function and way for you to press Play. Most of the features of all debuggers work on ARM MCUs but for exact details google is your friend!
 
 
-Happy debugging!
+Happy debugging!

docs/breaking_changes.md

@@ -10,16 +10,16 @@ The breaking change period is when we will merge PR's that change QMK in dangero
 
 ## When is the next Breaking Change?
 
-The next Breaking Change is scheduled for February 29, 2020.
+The next Breaking Change is scheduled for Nov 29.
 
 ### Important Dates
 
-* [x] 2019 Sep 21 - `future` is created. It will be rebased weekly.
-* [x] 2020 Feb 1 - `future` closed to new PR's.
-* [x] 2020 Feb 1 - Call for testers.
-* [ ] 2020 Feb 26 - `master` is locked, no PR's merged.
-* [ ] 2020 Feb 28 - Merge `future` to `master`.
-* [ ] 2020 Feb 29 - `master` is unlocked. PR's can be merged again.
+* [ ] 2019 Oct 04 - `future` is created. It will be rebased weekly.
+* [ ] 2019 Nov 01 - `future` closed to new PR's.
+* [ ] 2019 Nov 01 - Call for testers.
+* [ ] 2019 Nov 27 - `master` is locked, no PR's merged.
+* [ ] 2019 Nov 29 - Merge `future` to `master`.
+* [ ] 2019 Nov 30 - `master` is unlocked. PR's can be merged again.
 
 ## What changes will be included?
 
@@ -51,9 +51,7 @@ git rebase master
 git push --force
 ```
 
-## Creating the `future` branch
-
-This happens immediately after the previous `future` branch is merged.
+## 8 Weeks Before Merge
 
 * `qmk_firmware` git commands
     * [ ] `git checkout master`
@@ -67,6 +65,9 @@ This happens immediately after the previous `future` branch is merged.
     * [ ] `git tag <next_version>` # Prevent the breakpoint tag from confusing version incrementing
     * [ ] `git push origin future`
     * [ ] `git push --tags`
+* GitHub Actions
+    * [ ] Switch all [breaking_change PR's](https://github.com/qmk/qmk_firmware/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3Abreaking_change) to `future`
+    * [ ] Any that have a ChangeLog entry may be merged immediately.
 
 ## 4 Weeks Before Merge
 

docs/breaking_changes_instructions.md

@@ -1,42 +0,0 @@
-# Breaking Changes: My Pull Request Was Flagged
-
-A QMK member may have replied to your pull request stating that your submission is a breaking change. In their judgment, the changes you have proposed have greater implications for either QMK, or its users.
-
-Some things that may cause a pull request to be flagged are:
-
-- **Edits to User Keymaps**
-  A user may submit their keymap to QMK, then some time later open a pull request with further updates, only to find it can't be merged because it was edited in the `qmk/qmk_firmware` repository. As not all users are proficient at using Git or GitHub, the user may find themself unable to fix the issue on their own.
-- **Changes to Expected Behavior**
-  Changes to QMK behavior may cause users to believe their hardware or QMK is broken if they flash new firmware that incorporates changes to existing QMK features, and find themselves without a means to restore the desired behavior.
-- **Changes Requiring User Action**
-  Changes may also require action to be taken by users, such as updating a toolchain or taking some action in Git.
-- **Changes Necessitating Increased Scrutiny**
-  On occasion, a submission may have implications for QMK as a project. This could be copyright/licensing issues, coding conventions, large feature overhauls, "high-risk" changes that need wider testing by our community, or something else entirely.
-- **Changes Requiring Communication to End Users**
-  This includes warnings about future deprecations, outdated practices, and anything else that needs to be communicated but doesn't fit into one of the above categories.
-
-## What Do I Do?
-
-If it is determined that your submission is a breaking change, there are a few things you can do to smooth the process:
-
-### Consider Splitting Up Your PR
-
-If you are contributing core code, and the only reason it needs to go through breaking changes is that you are updating keymaps to match your change, consider whether you can submit your feature in a way that the old keymaps continue to work. Then submit a separate PR that goes through the breaking changes process to remove the old code.
-
-### Contribute a ChangeLog Entry
-
-We require submissions that go through the Breaking Change process to include a changelog entry. The entry should be a short summary of the changes your pull request makes – [each section here started as a changelog](ChangeLog/20190830.md "n.b. This should link to the 2019 Aug 30 Breaking Changes doc  - @noroadsleft").
-
-Your changelog should be located at `docs/ChangeLog/YYYYMMDD/PR####.md`, where `YYYYMMDD` is the date on which QMK's breaking change branch – usually named `future` – will be merged into the `master` branch, and `####` is the number of your pull request.
-
-If your submission requires action on the part of users, your changelog should instruct users what action(s) must be taken, or link to a location that does so.
-
-### Document Your Changes
-
-Understanding the purpose for your submission, and possible implications or actions it will require can make the review process more straightforward. A changelog may suffice for this purpose, but more extensive changes may require a level of detail that is ill-suited for a changelog.
-
-Commenting on your pull request and being responsive to questions, comments, and change requests is much appreciated.
-
-### Ask for Help
-
-Having your submission flagged may have caught you off guard. If you find yourself intimidated or overwhelmed, let us know. Comment on your pull request, or [reach out to the QMK team on Discord](https://discord.gg/Uq7gcHh).

docs/cli.md

@@ -4,84 +4,26 @@ This page describes how to setup and use the QMK CLI.
 
 # Overview
 
-The QMK CLI makes building and working with QMK keyboards easier. We have provided a number of commands to simplify and streamline tasks such as obtaining and compiling the QMK firmware, creating keymaps, and more.
+The QMK CLI makes building and working with QMK keyboards easier. We have provided a number of commands to help you work with QMK:
 
-* [Global CLI](#global-cli)
-* [Local CLI](#local-cli)
-* [CLI Commands](#cli-commands)
+* `qmk compile`
+* `qmk doctor`
 
-# Requirements
+# Setup
 
-The CLI requires Python 3.5 or greater. We try to keep the number of requirements small but you will also need to install the packages listed in [`requirements.txt`](https://github.com/qmk/qmk_firmware/blob/master/requirements.txt).
-
-# Global CLI
-
-QMK provides an installable CLI that can be used to setup your QMK build environment, work with QMK, and which makes working with multiple copies of `qmk_firmware` easier. We recommend installing and updating this periodically.
-
-## Install Using Homebrew (macOS, some Linux)
-
-If you have installed [Homebrew](https://brew.sh) you can tap and install QMK:
+Simply add the `qmk_firmware/bin` directory to your `PATH`. You can run the `qmk` commands from any directory.
 
 ```
-brew tap qmk/qmk
-brew install qmk
-export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
-qmk setup  # This will clone `qmk/qmk_firmware` and optionally set up your build environment
+export PATH=$PATH:$HOME/qmk_firmware/bin
 ```
 
-## Install Using easy_install or pip
+You may want to add this to your `.profile`, `.bash_profile`, `.zsh_profile`, or other shell startup scripts.
 
-If your system is not listed above you can install QMK manually. First ensure that you have python 3.5 (or later) installed and have installed pip. Then install QMK with this command:
-
-```
-pip3 install qmk
-export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
-qmk setup  # This will clone `qmk/qmk_firmware` and optionally set up your build environment
-```
-
-## Packaging For Other Operating Systems
-
-We are looking for people to create and maintain a `qmk` package for more operating systems. If you would like to create a package for your OS please follow these guidelines:
-
-* Follow best practices for your OS when they conflict with these guidelines
-    * Document why in a comment when you do deviate
-* Install using a virtualenv
-* Instruct the user to set the environment variable `QMK_HOME` to have the firmware source checked out somewhere other than `~/qmk_firmware`.
-
-# Local CLI
-
-If you do not want to use the global CLI there is a local CLI bundled with `qmk_firmware`. You can find it in `qmk_firmware/bin/qmk`. You can run the `qmk` command from any directory and it will always operate on that copy of `qmk_firmware`.
-
-**Example**:
-
-```
-$ ~/qmk_firmware/bin/qmk hello
-Ψ Hello, World!
-```
-
-## Local CLI Limitations
-
-There are some limitations to the local CLI compared to the global CLI:
-
-* The local CLI does not support `qmk setup` or `qmk clone`
-* The local CLI always operates on the same `qmk_firmware` tree, even if you have multiple repositories cloned.
-* The local CLI does not run in a virtualenv, so it's possible that dependencies will conflict
-
-# CLI Commands
-
-## `qmk cformat`
-
-This command formats C code using clang-format. Run it with no arguments to format all core code, or pass filenames on the command line to run it on specific files.
-
-**Usage**:
-
-```
-qmk cformat [file1] [file2] [...] [fileN]
-```
+# Commands
 
 ## `qmk compile`
 
-This command allows you to compile firmware from any directory. You can compile JSON exports from <https://config.qmk.fm>, compile keymaps in the repo, or compile the keyboard in the current working directory.
+This command allows you to compile firmware from any directory. You can compile JSON exports from <https://config.qmk.fm> or compile keymaps in the repo.
 
 **Usage for Configurator Exports**:
 
@@ -95,189 +37,12 @@ qmk compile <configuratorExport.json>
 qmk compile -kb <keyboard_name> -km <keymap_name>
 ```
 
-**Usage in Keyboard Directory**:  
+## `qmk cformat`
 
-Must be in keyboard directory with a default keymap, or in keymap directory for keyboard, or supply one with `--keymap <keymap_name>`
-```
-qmk compile
-```
-
-**Example**:
-```
-$ qmk config compile.keymap=default
-$ cd ~/qmk_firmware/keyboards/planck/rev6
-$ qmk compile
-Ψ Compiling keymap with make planck/rev6:default
-...
-```
-or with optional keymap argument
-
-```
-$ cd ~/qmk_firmware/keyboards/clueboard/66/rev4 
-$ qmk compile -km 66_iso
-Ψ Compiling keymap with make clueboard/66/rev4:66_iso
-...
-```
-or in keymap directory
-
-```
-$ cd ~/qmk_firmware/keyboards/gh60/satan/keymaps/colemak
-$ qmk compile
-Ψ Compiling keymap with make make gh60/satan:colemak
-...
-```
-
-**Usage in Layout Directory**:  
-
-Must be under `qmk_firmware/layouts/`, and in a keymap folder.
-```
-qmk compile -kb <keyboard_name>
-```
-
-**Example**:
-```
-$ cd ~/qmk_firmware/layouts/community/60_ansi/mechmerlin-ansi
-$ qmk compile -kb dz60
-Ψ Compiling keymap with make dz60:mechmerlin-ansi
-...
-```
-
-## `qmk flash`
-
-This command is similar to `qmk compile`, but can also target a bootloader. The bootloader is optional, and is set to `:flash` by default.
-To specify a different bootloader, use `-bl <bootloader>`. Visit <https://docs.qmk.fm/#/flashing>
-for more details of the available bootloaders.
-
-**Usage for Configurator Exports**:
-
-```
-qmk flash <configuratorExport.json> -bl <bootloader>
-```
-
-**Usage for Keymaps**:
-
-```
-qmk flash -kb <keyboard_name> -km <keymap_name> -bl <bootloader>
-```
-
-**Listing the Bootloaders**
-
-```
-qmk flash -b
-```
-
-## `qmk config`
-
-This command lets you configure the behavior of QMK. For the full `qmk config` documentation see [CLI Configuration](cli_configuration.md).
+This command formats C code using clang-format. Run it with no arguments to format all core code, or pass filenames on the command line to run it on specific files.
 
 **Usage**:
 
 ```
-qmk config [-ro] [config_token1] [config_token2] [...] [config_tokenN]
-```
-
-## `qmk docs`
-
-This command starts a local HTTP server which you can use for browsing or improving the docs. Default port is 8936.
-
-**Usage**:
-
-```
-qmk docs [-p PORT]
-```
-
-## `qmk doctor`
-
-This command examines your environment and alerts you to potential build or flash problems. It can fix many of them if you want it to.
-
-**Usage**:
-
-```
-qmk doctor [-y] [-n]
-```
-
-**Examples**:
-
-Check your environment for problems and prompt to fix them:
-
-    qmk doctor
-
-Check your environment and automatically fix any problems found:
-
-    qmk doctor -y
-
-Check your environment and report problems only:
-
-    qmk doctor -n
-
-## `qmk json-keymap`
-
-Creates a keymap.c from a QMK Configurator export.
-
-**Usage**:
-
-```
-qmk json-keymap [-o OUTPUT] filename
-```
-
-## `qmk kle2json`
-
-This command allows you to convert from raw KLE data to QMK Configurator JSON. It accepts either an absolute file path, or a file name in the current directory. By default it will not overwrite `info.json` if it is already present. Use the `-f` or `--force` flag to overwrite.
-
-**Usage**:
-
-```
-qmk kle2json [-f] <filename>
-```
-
-**Examples**:
-
-```
-$ qmk kle2json kle.txt 
-☒ File info.json already exists, use -f or --force to overwrite.
-```
-
-```
-$ qmk kle2json -f kle.txt -f
-Ψ Wrote out to info.json
-```
-
-## `qmk list-keyboards`
-
-This command lists all the keyboards currently defined in `qmk_firmware`
-
-**Usage**:
-
-```
-qmk list-keyboards
-```
-
-## `qmk new-keymap`
-
-This command creates a new keymap based on a keyboard's existing default keymap.
-
-**Usage**:
-
-```
-qmk new-keymap [-kb KEYBOARD] [-km KEYMAP]
-```
-
-## `qmk pyformat`
-
-This command formats python code in `qmk_firmware`.
-
-**Usage**:
-
-```
-qmk pyformat
-```
-
-## `qmk pytest`
-
-This command runs the python test suite. If you make changes to python code you should ensure this runs successfully.
-
-**Usage**:
-
-```
-qmk pytest
+qmk cformat [file1] [file2] [...] [fileN]
 ```

docs/cli_configuration.md

@@ -1,121 +0,0 @@
-# QMK CLI Configuration
-
-This document explains how `qmk config` works.
-
-# Introduction
-
-Configuration for QMK CLI is a key/value system. Each key consists of a subcommand and an argument name separated by a period. This allows for a straightforward and direct translation between config keys and the arguments they set.
-
-## Simple Example
-
-As an example let's look at the command `qmk compile --keyboard clueboard/66/rev4 --keymap default`.
-
-There are two command line arguments that could be read from configuration instead:
-
-* `compile.keyboard`
-* `compile.keymap`
-
-Let's set these now:
-
-```
-$ qmk config compile.keyboard=clueboard/66/rev4 compile.keymap=default
-compile.keyboard: None -> clueboard/66/rev4
-compile.keymap: None -> default
-Ψ Wrote configuration to '/Users/example/Library/Application Support/qmk/qmk.ini'
-```
-
-Now I can run `qmk compile` without specifying my keyboard and keymap each time.
-
-## Setting User Defaults
-
-Sometimes you want to share a setting between multiple commands. For example, multiple commands take the argument `--keyboard`. Rather than setting this value for every command you can set a user value which will be used by any command that takes that argument.
-
-Example:
-
-```
-$ qmk config user.keyboard=clueboard/66/rev4 user.keymap=default
-user.keyboard: None -> clueboard/66/rev4
-user.keymap: None -> default
-Ψ Wrote configuration to '/Users/example/Library/Application Support/qmk/qmk.ini'
-```
-
-# CLI Documentation (`qmk config`)
-
-The `qmk config` command is used to interact with the underlying configuration. When run with no argument it shows the current configuration. When arguments are supplied they are assumed to be configuration tokens, which are strings containing no spaces with the following form:
-
-    <subcommand|general|default>[.<key>][=<value>]
-
-## Setting Configuration Values
-
-You can set configuration values by putting an equal sign (=) into your config key. The key must always be the full `<section>.<key>` form.
-
-Example:
-
-```
-$ qmk config default.keymap=default
-default.keymap: None -> default
-Ψ Wrote configuration to '/Users/example/Library/Application Support/qmk/qmk.ini'
-```
-
-## Reading Configuration Values
-
-You can read configuration values for the entire configuration, a single key, or for an entire section. You can also specify multiple keys to display more than one value.
-
-### Entire Configuration Example
-
-    qmk config
-
-### Whole Section Example
-
-    qmk config compile
-
-### Single Key Example
-
-    qmk config compile.keyboard
-
-### Multiple Keys Example
-
-    qmk config user compile.keyboard compile.keymap
-
-## Deleting Configuration Values
-
-You can delete a configuration value by setting it to the special string `None`.
-
-Example:
-
-```
-$ qmk config default.keymap=None
-default.keymap: default -> None
-Ψ Wrote configuration to '/Users/example/Library/Application Support/qmk/qmk.ini'
-```
-
-## Multiple Operations
-
-You can combine multiple read and write operations into a single command. They will be executed and displayed in order:
-
-```
-$ qmk config compile default.keymap=default compile.keymap=None
-compile.keymap=skully
-compile.keyboard=clueboard/66_hotswap/gen1
-default.keymap: None -> default
-compile.keymap: skully -> None
-Ψ Wrote configuration to '/Users/example/Library/Application Support/qmk/qmk.ini'
-```
-
-# User Configuration Options
-
-| Key | Default Value | Description |
-|-----|---------------|-------------|
-| user.keyboard | None | The keyboard path (Example: `clueboard/66/rev4`) |
-| user.keymap | None | The keymap name (Example: `default`) |
-| user.name | None | The user's github username. |
-
-# All Configuration Options
-
-| Key | Default Value | Description |
-|-----|---------------|-------------|
-| compile.keyboard | None | The keyboard path (Example: `clueboard/66/rev4`) |
-| compile.keymap | None | The keymap name (Example: `default`) |
-| hello.name | None | The name to greet when run. |
-| new_keyboard.keyboard | None | The keyboard path (Example: `clueboard/66/rev4`) |
-| new_keyboard.keymap | None | The keymap name (Example: `default`) |

docs/cli_development.md

@@ -1,207 +0,0 @@
-# QMK CLI Development
-
-This document has useful information for developers wishing to write new `qmk` subcommands.
-
-# Overview
-
-The QMK CLI operates using the subcommand pattern made famous by git. The main `qmk` script is simply there to setup the environment and pick the correct entrypoint to run. Each subcommand is a self-contained module with an entrypoint (decorated by `@cli.subcommand()`) that performs some action and returns a shell returncode, or None.
-
-# Subcommands
-
-[MILC](https://github.com/clueboard/milc) is the CLI framework `qmk` uses to handle argument parsing, configuration, logging, and many other features. It lets you focus on writing your tool without wasting your time writing glue code.
-
-Subcommands in the local CLI are always found in `qmk_firmware/lib/python/qmk/cli`.
-
-Let's start by looking at an example subcommand. This is `lib/python/qmk/cli/hello.py`:
-
-```python
-"""QMK Python Hello World
-
-This is an example QMK CLI script.
-"""
-from milc import cli
-
-
-@cli.argument('-n', '--name', default='World', help='Name to greet.')
-@cli.subcommand('QMK Hello World.')
-def hello(cli):
-    """Log a friendly greeting.
-    """
-    cli.log.info('Hello, %s!', cli.config.hello.name)
-```
-
-First we import the `cli` object from `milc`. This is how we interact with the user and control the script's behavior. We use `@cli.argument()` to define a command line flag, `--name`. This also creates a configuration variable named `hello.name` (and the corresponding `user.name`) which the user can set so they don't have to specify the argument. The `cli.subcommand()` decorator designates this function as a subcommand. The name of the subcommand will be taken from the name of the function.
-
-Once inside our function we find a typical "Hello, World!" program. We use `cli.log` to access the underlying [Logger Object](https://docs.python.org/3.5/library/logging.html#logger-objects), whose behavior is user controllable. We also access the value for name supplied by the user as `cli.config.hello.name`. The value for `cli.config.hello.name` will be determined by looking at the `--name` argument supplied by the user, if not provided it will use the value in the `qmk.ini` config file, and if neither of those is provided it will fall back to the default supplied in the `cli.argument()` decorator.
-
-# User Interaction
-
-MILC and the QMK CLI have several nice tools for interacting with the user. Using these standard tools will allow you to colorize your text for easier interactions, and allow the user to control when and how that information is displayed and stored.
-
-## Printing Text
-
-There are two main methods for outputting text in a subcommand- `cli.log` and `cli.echo()`. They operate in similar ways but you should prefer to use `cli.log.info()` for most general purpose printing.
-
-You can use special tokens to colorize your text, to make it easier to understand the output of your program. See [Colorizing Text](#colorizing-text) below.
-
-Both of these methods support built-in string formatting using python's [printf style string format operations](https://docs.python.org/3.5/library/stdtypes.html#old-string-formatting). You can use tokens such as `%s` and `%d` within your text strings then pass the values as arguments. See our Hello, World program above for an example.
-
-You should never use the format operator (`%`) directly, always pass values as arguments.
-
-### Logging (`cli.log`)
-
-The `cli.log` object gives you access to a [Logger Object](https://docs.python.org/3.5/library/logging.html#logger-objects). We have configured our log output to show the user a nice emoji for each log level (or the log level name if their terminal does not support unicode.) This way the user can tell at a glance which messages are most important when something goes wrong.
-
-The default log level is `INFO`. If the user runs `qmk -v <subcommand>` the default log level will be set to `DEBUG`.
-
-| Function | Emoji |
-|----------|-------|
-| cli.log.critical | `{bg_red}{fg_white}¬_¬{style_reset_all}` |
-| cli.log.error | `{fg_red}☒{style_reset_all}` |
-| cli.log.warning | `{fg_yellow}⚠{style_reset_all}` |
-| cli.log.info | `{fg_blue}Ψ{style_reset_all}` |
-| cli.log.debug | `{fg_cyan}☐{style_reset_all}` |
-| cli.log.notset | `{style_reset_all}¯\\_(o_o)_/¯` |
-
-### Printing (`cli.echo`)
-
-Sometimes you simply need to print text outside of the log system. This is appropriate if you are outputting fixed data or writing out something that should never be logged. Most of the time you should prefer `cli.log.info()` over `cli.echo`.
-
-### Colorizing Text
-
-You can colorize the output of your text by including color tokens within text. Use color to highlight, not to convey information. Remember that the user can disable color, and your subcommand should still be usable if they do.
-
-You should generally avoid setting the background color, unless it's integral to what you are doing. Remember that users have a lot of preferences when it comes to their terminal color, so you should pick colors that work well against both black and white backgrounds.
-
-Colors prefixed with 'fg' will affect the foreground (text) color. Colors prefixed with 'bg' will affect the background color.
-
-| Color | Background | Extended Background | Foreground | Extended Foreground|
-|-------|------------|---------------------|------------|--------------------|
-| Black | {bg_black} | {bg_lightblack_ex} | {fg_black} | {fg_lightblack_ex} |
-| Blue | {bg_blue} | {bg_lightblue_ex} | {fg_blue} | {fg_lightblue_ex} |
-| Cyan | {bg_cyan} | {bg_lightcyan_ex} | {fg_cyan} | {fg_lightcyan_ex} |
-| Green | {bg_green} | {bg_lightgreen_ex} | {fg_green} | {fg_lightgreen_ex} |
-| Magenta | {bg_magenta} | {bg_lightmagenta_ex} | {fg_magenta} | {fg_lightmagenta_ex} |
-| Red | {bg_red} | {bg_lightred_ex} | {fg_red} | {fg_lightred_ex} |
-| White | {bg_white} | {bg_lightwhite_ex} | {fg_white} | {fg_lightwhite_ex} |
-| Yellow | {bg_yellow} | {bg_lightyellow_ex} | {fg_yellow} | {fg_lightyellow_ex} |
-
-There are also control sequences that can be used to change the behavior of
-ANSI output:
-
-| Control Sequences | Description |
-|-------------------|-------------|
-| {style_bright} | Make the text brighter |
-| {style_dim} | Make the text dimmer |
-| {style_normal} | Make the text normal (neither `{style_bright}` nor `{style_dim}`) |
-| {style_reset_all} | Reset all text attributes to default. (This is automatically added to the end of every string.) |
-| {bg_reset} | Reset the background color to the user's default |
-| {fg_reset} | Reset the foreground color to the user's default |
-
-# Arguments and Configuration
-
-QMK handles the details of argument parsing and configuration for you. When you add a new argument it is automatically incorporated into the config tree based on your subcommand's name and the long name of the argument. You can access this configuration in `cli.config`, using either attribute-style access (`cli.config.<subcommand>.<argument>`) or dictionary-style access (`cli.config['<subcommand>']['<argument>']`).
-
-Under the hood QMK uses [ConfigParser](https://docs.python.org/3/library/configparser.html) to store configurations. This gives us an easy and straightforward way to represent the configuration in a human-editable way. We have wrapped access to this configuration to provide some nicities that ConfigParser does not normally have.
-
-## Reading Configuration Values
-
-You can interact with `cli.config` in all the ways you'd normally expect. For example the `qmk compile` command gets the keyboard name from `cli.config.compile.keyboard`. It does not need to know whether that value came from the command line, an environment variable, or the configuration file.
-
-Iteration is also supported:
-
-```
-for section in cli.config:
-    for key in cli.config[section]:
-        cli.log.info('%s.%s: %s', section, key, cli.config[section][key])
-```
-
-## Setting Configuration Values
-
-You can set configuration values in the usual ways.
-
-Dictionary style:
-
-```
-cli.config['<section>']['<key>'] = <value>
-```
-
-Attribute style:
-
-```
-cli.config.<section>.<key> = <value>
-```
-
-## Deleting Configuration Values
-
-You can delete configuration values in the usual ways.
-
-Dictionary style:
-
-```
-del(cli.config['<section>']['<key>'])
-```
-
-Attribute style:
-
-```
-del(cli.config.<section>.<key>)
-```
-
-## Writing The Configuration File
-
-The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberitely using `qmk config`.
-
-You can use `cli.save_config()` to write out the configuration.
-
-## Excluding Arguments From Configuration
-
-Some arguments should not be propagated to the configuration file. These can be excluded by adding `arg_only=True` when creating the argument.
-
-Example:
-
-```
-@cli.argument('-o', '--output', arg_only=True, help='File to write to')
-@cli.argument('filename', arg_only=True, help='Configurator JSON file')
-@cli.subcommand('Create a keymap.c from a QMK Configurator export.')
-def json_keymap(cli):
-    pass
-```
-
-You will only be able to access these arguments using `cli.args`. For example:
-
-```
-cli.log.info('Reading from %s and writing to %s', cli.args.filename, cli.args.output)
-```
-
-# Testing, and Linting, and Formatting (oh my!)
-
-We use nose2, flake8, and yapf to test, lint, and format code. You can use the `pytest` and `pyformat` subcommands to run these tests:
-
-### Testing and Linting
-
-    qmk pytest
-
-### Formatting
-
-    qmk pyformat
-
-## Formatting Details
-
-We use [yapf](https://github.com/google/yapf) to automatically format code. Our configuration is in the `[yapf]` section of `setup.cfg`.
-
-?> Tip- Many editors can use yapf as a plugin to automatically format code as you type.
-
-## Testing Details
-
-Our tests can be found in `lib/python/qmk/tests/`. You will find both unit and integration tests in this directory. We hope you will write both unit and integration tests for your code, but if you do not please favor integration tests. 
-
-If your PR does not include a comprehensive set of tests please add comments like this to your code so that other people know where they can help:
-
-    # TODO(unassigned/<yourGithubUsername>): Write <unit|integration> tests
-
-We use [nose2](https://nose2.readthedocs.io/en/latest/getting_started.html) to run our tests. You can refer to the nose2 documentation for more details on what you can do in your test functions.
-
-## Linting Details
-
-We use flake8 to lint our code. Your code should pass flake8 before you open a PR. This will be checked when you run `qmk pytest` and by CI when you submit a PR.

docs/coding_conventions_c.md

@@ -14,7 +14,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
   * Think of them as a story describing the feature
   * Use them liberally to explain why particular decisions were made.
   * Do not write obvious comments
-  * If you're not sure if a comment is obvious, go ahead and include it.
+  * If you not sure if a comment is obvious, go ahead and include it.
 * In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
 * We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`)
 * We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`
@@ -31,17 +31,17 @@ Here is an example for easy reference:
 ```c
 /* Enums for foo */
 enum foo_state {
-    FOO_BAR,
-    FOO_BAZ,
+  FOO_BAR,
+  FOO_BAZ,
 };
 
 /* Returns a value */
 int foo(void) {
-    if (some_condition) {
-        return FOO_BAR;
-    } else {
-        return -1;
-    }
+  if (some_condition) {
+    return FOO_BAR;
+  } else {
+    return -1;
+  }
 }
 ```