Tags: Oreo48662/specification
Tags
Clarify that cores report all keys, whether or not supported (editorc… …onfig#37) * Terminology: mention key-value pairs - Clarify that cores produce, and plugins consume, key-value pairs. - Clarify that a plugin should ignore invalid/unsupported values, regardless of whether the plugin recognizes that key. - Bump version to 0.15.1. This is a PATCH level change since it documents existing behaviour more clearly. * Clarify that cores process all key-value pairs, whether or not supported The core tests use many key-value pairs with keys that are not defined as "Supported Pairs" in the specification. Clarify that cores must report all key-value pairs, regardless of whether those pairs are listed in the spec as supported. It is up to the plugin to ignore keys it does not recognize. * Rename "Terms" to "Parts of an EditorConfig file" To distinguish that section from "Terminology"
Clarify that cores report all keys, whether or not supported (editorc… …onfig#37) * Terminology: mention key-value pairs - Clarify that cores produce, and plugins consume, key-value pairs. - Clarify that a plugin should ignore invalid/unsupported values, regardless of whether the plugin recognizes that key. - Bump version to 0.15.1. This is a PATCH level change since it documents existing behaviour more clearly. * Clarify that cores process all key-value pairs, whether or not supported The core tests use many key-value pairs with keys that are not defined as "Supported Pairs" in the specification. Clarify that cores must report all key-value pairs, regardless of whether those pairs are listed in the spec as supported. It is up to the plugin to ignore keys it does not recognize. * Rename "Terms" to "Parts of an EditorConfig file" To distinguish that section from "Terminology"
Remove the description of inline comments at all (editorconfig#31) * Remove the description of inline comments at all It looks like the current wording still leads to too much confusion: editorconfig#29 (comment) I therefore propose to remove the explaining addition about inline comments at all, in favor of a description of the former behavior of EditorConfig parsers. * Simplify the reference to formerly allowed inline comments * Make a new subsection for the definitions of terms * No inline comments; bump spec to 0.15.0 - Clarify that inline comments are _not_ supported. See <editorconfig#31 (comment)> - Bump the specification to 0.15.0 as a warning, since this change will break cores that have been supporting inline comments. Co-authored-by: Chris White <cxwembedded@gmail.com>
Implement versioning changes (editorconfig#17) - Make changes specified by editorconfig/editorconfig-vote#11 - Add definitions of terms to make the versioning section clearer - Minor cleanup