From f275ffbdfc1cbd1965cd3546b45a7838012321da Mon Sep 17 00:00:00 2001 From: osjuga <43299093+osjuga@users.noreply.github.com> Date: Sat, 7 Dec 2019 07:19:18 -0500 Subject: [PATCH] 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 --- docs/coding_conventions_c.md | 2 +- docs/coding_conventions_python.md | 2 +- docs/feature_haptic_feedback.md | 2 +- 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 08994bfbb..16e28b288 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 694aa38cf..9dd95e4b7 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 227363322..ff7337a51 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 5b834a99d..5695acc50 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: