diff options
| author | osjuga <43299093+osjuga@users.noreply.github.com> | 2019-12-07 07:19:18 -0500 |
|---|---|---|
| committer | fauxpark <fauxpark@gmail.com> | 2019-12-07 23:19:18 +1100 |
| commit | f275ffbdfc1cbd1965cd3546b45a7838012321da (patch) | |
| tree | 548dba9d1d37dd236dfee8e97ebca5088c6989c6 | |
| parent | 36a6e269bfff8b557a92e3c5e7a4a104d0dfe5f7 (diff) | |
Minor grammar and filename fixes in docs (#7559)
Grammar in coding_conventions_c.md and coding_conventions_python.md
`rule.mk` to `rules.mk` in feature_haptic_feedback.md and feature_rgb_matrix.md
| -rw-r--r-- | docs/coding_conventions_c.md | 2 | ||||
| -rw-r--r-- | docs/coding_conventions_python.md | 2 | ||||
| -rw-r--r-- | docs/feature_haptic_feedback.md | 2 | ||||
| -rw-r--r-- | docs/feature_rgb_matrix.md | 2 |
4 files changed, 4 insertions, 4 deletions
diff --git a/docs/coding_conventions_c.md b/docs/coding_conventions_c.md index 08994bfbb7..16e28b2884 100644 --- a/docs/coding_conventions_c.md +++ b/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 not sure if a comment is obvious, go ahead and include it. + * If you're 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)` diff --git a/docs/coding_conventions_python.md b/docs/coding_conventions_python.md index 694aa38cfc..9dd95e4b73 100644 --- a/docs/coding_conventions_python.md +++ b/docs/coding_conventions_python.md @@ -8,7 +8,7 @@ Most of our style follows PEP8 with some local modifications to make things less * 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 not sure if a comment is obvious, go ahead and include it. + * If you're not sure if a comment is obvious, go ahead and include it. * We require useful docstrings for all functions. * 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. * Some of our practices conflict with the wider python community to make our codebase more approachable to non-pythonistas. diff --git a/docs/feature_haptic_feedback.md b/docs/feature_haptic_feedback.md index 2273633227..ff7337a51a 100644 --- a/docs/feature_haptic_feedback.md +++ b/docs/feature_haptic_feedback.md @@ -2,7 +2,7 @@ ## Haptic feedback rules.mk options -The following options are currently available for haptic feedback in `rule.mk`: +The following options are currently available for haptic feedback in `rules.mk`: `HAPTIC_ENABLE += DRV2605L` diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md index 5b834a99d5..5695acc508 100644 --- a/docs/feature_rgb_matrix.md +++ b/docs/feature_rgb_matrix.md @@ -286,7 +286,7 @@ You can disable a single effect by defining `DISABLE_[EFFECT_NAME]` in your `con ## Custom RGB Matrix Effects -By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rule.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files. +By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rules.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files. To declare new effects, create a new `rgb_matrix_user/kb.inc` that looks something like this: |