mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 13:50:10 +01:00
Adjust md tab width to work better cross-markdown-parser (#124)
We're running into issues with md handlers that expect this kind of 4-space indent. It should be cross-compatible with GH, so switch, even though it feels a little churny.
Manual edits are to:
- .prettierrc.yaml:
- rename from .prettierrc
- add tabWidth (primary change)
- add trailingComma (fix vimPrettier skew)
- contribution_tools.md: Fix remarks about .prettierrc.yaml
- pre-commit-toc.js: indent, bullets
- pre-commit-proposal-list.py: indent of output
The rest is the result of `pre-commit run --all-files`
Unfortunately this'll probably depend on the change being propagated into PR branches, so I wouldn't be surprised if we see regressions for a bit. We'll also need to nudge people to update .vimrc's. Hopefully the pre-commit GH action helps catch issues.
This commit is contained in:
Jon Meow
GitHub
+38
-38
@@ -10,28 +10,28 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
- [Overview](#overview)
|
||||
- [Project goals](#project-goals)
|
||||
- [Community and culture](#community-and-culture)
|
||||
- [Language tools and ecosystem](#language-tools-and-ecosystem)
|
||||
- [Language goals and priorities](#language-goals-and-priorities)
|
||||
- [Goals in detail](#goals-in-detail)
|
||||
- [Performance-critical software](#performance-critical-software)
|
||||
- [Software and language evolution](#software-and-language-evolution)
|
||||
- [Code that is easy to read, understand, and write](#code-that-is-easy-to-read-understand-and-write)
|
||||
- [Practical safety guarantees and testing mechanisms](#practical-safety-guarantees-and-testing-mechanisms)
|
||||
- [Fast and scalable development](#fast-and-scalable-development)
|
||||
- [Modern OS platforms, hardware architectures, and environments](#modern-os-platforms-hardware-architectures-and-environments)
|
||||
- [Interoperability with and migration from existing C++ code](#interoperability-with-and-migration-from-existing-c-code)
|
||||
- [Non-goals](#non-goals)
|
||||
- [Stable language and library ABI](#stable-language-and-library-abi)
|
||||
- [Backwards or forwards compatibility](#backwards-or-forwards-compatibility)
|
||||
- [Legacy compiled libraries without source code or ability to rebuild](#legacy-compiled-libraries-without-source-code-or-ability-to-rebuild)
|
||||
- [Support for existing compilation and linking models](#support-for-existing-compilation-and-linking-models)
|
||||
- [Idiomatic migration of non-modern, non-idiomatic C++ code](#idiomatic-migration-of-non-modern-non-idiomatic-c-code)
|
||||
- [Principles](#principles)
|
||||
- [Prioritization beyond goals](#prioritization-beyond-goals)
|
||||
- [Acknowledgements](#acknowledgements)
|
||||
- [Overview](#overview)
|
||||
- [Project goals](#project-goals)
|
||||
- [Community and culture](#community-and-culture)
|
||||
- [Language tools and ecosystem](#language-tools-and-ecosystem)
|
||||
- [Language goals and priorities](#language-goals-and-priorities)
|
||||
- [Goals in detail](#goals-in-detail)
|
||||
- [Performance-critical software](#performance-critical-software)
|
||||
- [Software and language evolution](#software-and-language-evolution)
|
||||
- [Code that is easy to read, understand, and write](#code-that-is-easy-to-read-understand-and-write)
|
||||
- [Practical safety guarantees and testing mechanisms](#practical-safety-guarantees-and-testing-mechanisms)
|
||||
- [Fast and scalable development](#fast-and-scalable-development)
|
||||
- [Modern OS platforms, hardware architectures, and environments](#modern-os-platforms-hardware-architectures-and-environments)
|
||||
- [Interoperability with and migration from existing C++ code](#interoperability-with-and-migration-from-existing-c-code)
|
||||
- [Non-goals](#non-goals)
|
||||
- [Stable language and library ABI](#stable-language-and-library-abi)
|
||||
- [Backwards or forwards compatibility](#backwards-or-forwards-compatibility)
|
||||
- [Legacy compiled libraries without source code or ability to rebuild](#legacy-compiled-libraries-without-source-code-or-ability-to-rebuild)
|
||||
- [Support for existing compilation and linking models](#support-for-existing-compilation-and-linking-models)
|
||||
- [Idiomatic migration of non-modern, non-idiomatic C++ code](#idiomatic-migration-of-non-modern-non-idiomatic-c-code)
|
||||
- [Principles](#principles)
|
||||
- [Prioritization beyond goals](#prioritization-beyond-goals)
|
||||
- [Acknowledgements](#acknowledgements)
|
||||
|
||||
<!-- tocstop -->
|
||||
|
||||
@@ -296,22 +296,22 @@ activities where humans interact with Carbon: reading, writing, designing,
|
||||
discussing, reviewing, and refactoring code, as well as learning and teaching
|
||||
Carbon. A few examples:
|
||||
|
||||
- Carbon should not use symbols that are difficult to type, see, or
|
||||
differentiate from similar symbols in commonly used contexts.
|
||||
- Syntax should be easily parsed and scanned by any human in any development
|
||||
environment, not just a machine or a human aided by semantic hints from an
|
||||
IDE.
|
||||
- Code with similar behavior should use similar syntax, and code with different
|
||||
behavior should use different syntax. Behavior in this context should include
|
||||
both the functionality and performance of the code. This is part of conceptual
|
||||
integrity.
|
||||
- Explicitness must be balanced against conciseness, as verbosity and ceremony
|
||||
add cognitive overhead for the reader, while explicitness reduces the amount
|
||||
of outside context the reader must have or assume.
|
||||
- Common yet complex tasks, such as parallel code, should be well-supported in
|
||||
ways that are easy to reason about.
|
||||
- Ordinary tasks should not require extraordinary care, because humans cannot
|
||||
consistently avoid making mistakes for an extended amount of time.
|
||||
- Carbon should not use symbols that are difficult to type, see, or
|
||||
differentiate from similar symbols in commonly used contexts.
|
||||
- Syntax should be easily parsed and scanned by any human in any development
|
||||
environment, not just a machine or a human aided by semantic hints from an
|
||||
IDE.
|
||||
- Code with similar behavior should use similar syntax, and code with
|
||||
different behavior should use different syntax. Behavior in this context
|
||||
should include both the functionality and performance of the code. This is
|
||||
part of conceptual integrity.
|
||||
- Explicitness must be balanced against conciseness, as verbosity and ceremony
|
||||
add cognitive overhead for the reader, while explicitness reduces the amount
|
||||
of outside context the reader must have or assume.
|
||||
- Common yet complex tasks, such as parallel code, should be well-supported in
|
||||
ways that are easy to reason about.
|
||||
- Ordinary tasks should not require extraordinary care, because humans cannot
|
||||
consistently avoid making mistakes for an extended amount of time.
|
||||
|
||||
**Support tooling at every layer of the development experience, including
|
||||
IDEs.** The design and implementation of Carbon should make it easy to create
|
||||
|
||||
Reference in New Issue
Block a user