doc: *.md formatting fixes in the top-level dir

Continuing what a58b48b did for the doc/ dir, this fixes some formatting issues in the *.md files that are placed directly in the top-level directory. README.md changes are excluded as they are covered by #7971 Refs: #7637 PR-URL: #7727 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Michaël Zasso <mic.besace@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
nodejs · ChALkeR · Aug 4, 2016 · Jul 14, 2016 · Jul 14, 2016 · Jul 14, 2016
commit 4aa8120aeab54a87568e51feb945b7ae2809f8ae
diff --git a/BUILDING.md b/BUILDING.md
@@ -28,7 +28,7 @@ On FreeBSD and OpenBSD, you may also need:
 * libexecinfo (FreeBSD and OpenBSD only)
 
 
-```text
+```console
 $ ./configure
 $ make
 $ [sudo] make install
@@ -37,7 +37,7 @@ $ [sudo] make install
 If your Python binary is in a non-standard location or has a
 non-standard name, run the following instead:
 
-```text
+```console
 $ export PYTHON=/path/to/python
 $ $PYTHON ./configure
 $ make
@@ -46,13 +46,13 @@ $ [sudo] make install
 
 To run the tests:
 
-```text
+```console
 $ make test
 ```
 
 To run the native module tests:
 
-```text
+```console
 $ make test-addons
 ```
 
@@ -61,35 +61,35 @@ To run the npm test suite:
 *note: to run the suite on node v4 or earlier you must first*
 *run `make install`*
 
-```
+```console
 $ make test-npm
 ```
 
 To build the documentation:
 
 This will build Node.js first (if necessary) and then use it to build the docs:
 
-```text
+```console
 $ make doc
 ```
 
 If you have an existing Node.js you can build just the docs with:
 
-```text
+```console
 $ NODE=node make doc-only
 ```
 
 (Where `node` is the path to your executable.)
 
 To read the documentation:
 
-```text
+```console
 $ man doc/node.1
 ```
 
 To test if Node.js was built correctly:
 
-```
+```console
 $ node -e "console.log('Hello from Node.js ' + process.version)"
 ```
 
@@ -107,19 +107,19 @@ Prerequisites:
   [Git for Windows](http://git-scm.com/download/win) includes Git Bash
   and tools which can be included in the global `PATH`.
 
-```text
+```console
 > vcbuild nosign
 ```
 
 To run the tests:
 
-```text
+```console
 > vcbuild test
 ```
 
 To test if Node.js was built correctly:
 
-```text
+```console
 > Release\node -e "console.log('Hello from Node.js', process.version)"
 ```
 
@@ -136,7 +136,7 @@ Be sure you have downloaded and extracted [Android NDK]
 (https://developer.android.com/tools/sdk/ndk/index.html)
 before in a folder. Then run:
 
-```
+```console
 $ ./android-configure /path/to/your/android-ndk
 $ make
 ```
@@ -165,13 +165,13 @@ Node.js source does not include all locales.)
 
 ##### Unix / OS X:
 
-```text
+```console
 $ ./configure --with-intl=full-icu --download=all
 ```
 
 ##### Windows:
 
-```text
+```console
 > vcbuild full-icu download-all
 ```
 
@@ -182,19 +182,19 @@ The `Intl` object will not be available, nor some other APIs such as
 
 ##### Unix / OS X:
 
-```text
+```console
 $ ./configure --without-intl
 ```
 
 ##### Windows:
 
-```text
+```console
 > vcbuild without-intl
 ```
 
 #### Use existing installed ICU (Unix / OS X only):
 
-```text
+```console
 $ pkg-config --modversion icu-i18n && ./configure --with-intl=system-icu
 ```
 
@@ -210,14 +210,18 @@ Download the file named something like `icu4c-**##.#**-src.tgz` (or
 
 ##### Unix / OS X
 
-```text
-# from an already-unpacked ICU:
+From an already-unpacked ICU:
+```console
 $ ./configure --with-intl=[small-icu,full-icu] --with-icu-source=/path/to/icu
+```
 
-# from a local ICU tarball
+From a local ICU tarball:
+```console
 $ ./configure --with-intl=[small-icu,full-icu] --with-icu-source=/path/to/icu.tgz
+```
 
-# from a tarball URL
+From a tarball URL:
+```console
 $ ./configure --with-intl=full-icu --with-icu-source=http://url/to/icu.tgz
 ```
 
@@ -227,7 +231,7 @@ First unpack latest ICU to `deps/icu`
 [icu4c-**##.#**-src.tgz](http://icu-project.org/download) (or `.zip`)
 as `deps/icu` (You'll have: `deps/icu/source/...`)
 
-```text
+```console
 > vcbuild full-icu
 ```
 

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -100,7 +100,7 @@ changed and why. Follow these guidelines when writing one:
 
 A good commit log can look something like this:
 
-```
+```txt
 subsystem: explaining the commit in one line
 
 Body of commit message is a few lines of text, explaining things
@@ -122,7 +122,7 @@ what subsystem (or subsystems) your changes touch.
 If your patch fixes an open issue, you can add a reference to it at the end
 of the log. Use the `Fixes:` prefix and the full issue URL. For example:
 
-```
+```txt
 Fixes: https://github.com/nodejs/node/issues/1337
 ```