Merge pull request #2664 from atom/jl-docs-dev

Standardize Docs: Development

docs-translations/es/README-es.md

@@ -62,7 +62,7 @@ Módulos de ambos procesos:
 * [Estructura de directorio](development/source-code-directory-structure.md)
 * [Diferencias técnicas con NW.js (anteriormente conocido como node-webkit)](development/atom-shell-vs-node-webkit.md)
 * [Sistema de compilación](development/build-system-overview.md)
-* [Instrucciones de compilación (Mac)](development/build-instructions-mac.md)
+* [Instrucciones de compilación (Mac)](development/build-instructions-osx.md)
 * [Instrucciones de compilación (Windows)](development/build-instructions-windows.md)
 * [Instrucciones de compilación (Linux)](development/build-instructions-linux.md)
 * [Configurando un servidor de símbolos en el depurador](development/setting-up-symbol-server.md)

docs-translations/ko/README.md

@@ -64,7 +64,7 @@
 * [소스 코드 디렉터리 구조](development/source-code-directory-structure.md)
 * [NW.js(node-webkit)와 기술적으로 다른점](development/atom-shell-vs-node-webkit.md)
 * [빌드 시스템 개요](development/build-system-overview.md)
-* [빌드 설명서 (Mac)](development/build-instructions-mac.md)
+* [빌드 설명서 (Mac)](development/build-instructions-osx.md)
 * [빌드 설명서 (Windows)](development/build-instructions-windows.md)
 * [빌드 설명서 (Linux)](development/build-instructions-linux.md)
 * [디버거에서 디버그 심볼 서버 설정](development/setting-up-symbol-server.md)

docs/README.md

@@ -64,7 +64,7 @@ Modules for both processes:
 * [Source code directory structure](development/source-code-directory-structure.md)
 * [Technical differences to NW.js (formerly node-webkit)](development/atom-shell-vs-node-webkit.md)
 * [Build system overview](development/build-system-overview.md)
-* [Build instructions (Mac)](development/build-instructions-mac.md)
+* [Build instructions (Mac)](development/build-instructions-osx.md)
 * [Build instructions (Windows)](development/build-instructions-windows.md)
 * [Build instructions (Linux)](development/build-instructions-linux.md)
 * [Setting up symbol server in debugger](development/setting-up-symbol-server.md)

docs/development/atom-shell-vs-node-webkit.md

@@ -1,18 +1,18 @@
-# Technical differences to NW.js (formerly node-webkit)
+# Technical Differences Between Electron and NW.js (formerly node-webkit)
 
 __Note: Electron was previously named Atom Shell.__
 
 Like NW.js, Electron provides a platform to write desktop applications
-with JavaScript and HTML and has Node integration to grant access to low level
+with JavaScript and HTML and has Node integration to grant access to the low
-system in web pages.
+level system from web pages.
 
 But there are also fundamental differences between the two projects that make
 Electron a completely separate product from NW.js:
 
-__1. Entry of application__
+__1. Entry of Application__
 
-In NW.js, the main entry of an application is a web page. You specify a
+In NW.js the main entry point of an application is a web page. You specify a
-main page in the `package.json` and it is opened in a browser window as
+main page URL in the `package.json` and it is opened in a browser window as
 the application's main window.
 
 In Electron, the entry point is a JavaScript script. Instead of
@@ -23,19 +23,18 @@ to decide when to quit the application.
 Electron works more like the Node.js runtime. Electron's APIs are lower level
 so you can use it for browser testing in place of [PhantomJS](http://phantomjs.org/).
 
-__2. Build system__
+__2. Build System__
 
-In order to avoid the complexity of building the whole Chromium, Electron uses
+In order to avoid the complexity of building all of Chromium, Electron uses [`libchromiumcontent`](https://github.com/brightray/libchromiumcontent) to access
-[libchromiumcontent](https://github.com/brightray/libchromiumcontent) to access
+Chromium's Content API. `libchromiumcontent` is a single shared library that
-Chromium's Content API. libchromiumcontent is a single, shared library that
+includes the Chromium Content module and all of its dependencies. Users don't
-includes the Chromium Content module and all its dependencies. Users don't
 need a powerful machine to build Electron.
 
-__3. Node integration__
+__3. Node Integration__
 
 In NW.js, the Node integration in web pages requires patching Chromium to
-work, while in Electron we chose a different way to integrate libuv loop with
+work, while in Electron we chose a different way to integrate the libuv loop
-each platform's message loop to avoid hacking Chromium. See the
+with each platform's message loop to avoid hacking Chromium. See the
 [`node_bindings`](../../atom/common/) code for how that was done.
 
 __4. Multi-context__

docs/development/build-instructions-linux.md

@@ -1,15 +1,17 @@
-# Build instructions (Linux)
+# Build Instructions (Linux)
+
+Follow the guidelines below for building Electron on Linux.
 
 ## Prerequisites
 
 * Python 2.7.x. Some distributions like CentOS still use Python 2.6.x
   so you may need to check your Python version with `python -V`.
-* Node.js v0.12.x. There are various ways to install Node. One can download
+* Node.js v0.12.x. There are various ways to install Node. You can download
   source code from [Node.js](http://nodejs.org) and compile from source.
-Doing so permits installing Node to your own home directory as a standard user.
+  Doing so permits installing Node on your own home directory as a standard user.
-Or try repositories such as [NodeSource] (https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories)
+  Or try repositories such as [NodeSource](https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories).
-* Clang 3.4 or later
+* Clang 3.4 or later.
-* Development headers of GTK+ and libnotify
+* Development headers of GTK+ and libnotify.
 
 On Ubuntu, install the following libraries:
 
@@ -33,10 +35,10 @@ managers such as pacman. Or one can compile from source code.
 
 ## If You Use Virtual Machines For Building
 
-If you plan to build electron on a virtual machine, you will need a fixed-size
+If you plan to build Electron on a virtual machine you will need a fixed-size
 device container of at least 25 gigabytes in size.
 
-## Getting the code
+## Getting the Code
 
 ```bash
 $ git clone https://github.com/atom/electron.git
@@ -45,8 +47,8 @@ $ git clone https://github.com/atom/electron.git
 ## Bootstrapping
 
 The bootstrap script will download all necessary build dependencies and create
-build project files. You must have Python 2.7.x for the script to succeed.
+the build project files. You must have Python 2.7.x for the script to succeed.
-Downloading certain files could take a long time. Notice that we are using
+Downloading certain files can take a long time. Notice that we are using
 `ninja` to build Electron so there is no `Makefile` generated.
 
 ```bash
@@ -56,7 +58,7 @@ $ ./script/bootstrap.py -v
 
 ### Cross compilation
 
-If you want to build for `arm` target, you should also install following
+If you want to build for an `arm` target you should also install the following
 dependencies:
 
 ```bash
@@ -90,7 +92,7 @@ $ ./script/create-dist.py
 
 This will put a working distribution with much smaller file sizes in
 the `dist` directory. After running the create-dist.py script, you
-may want to remove the 1.3+ gigabyte binary which is still in out/R.
+may want to remove the 1.3+ gigabyte binary which is still in `out/R`.
 
 You can also build the `Debug` target only:
 
@@ -110,12 +112,12 @@ $ ./script/clean.py
 
 ## Troubleshooting
 
-Make sure you have installed all the build dependencies.
+Make sure you have installed all of the build dependencies.
 
-### error while loading shared libraries: libtinfo.so.5
+### Error While Loading Shared Libraries: libtinfo.so.5
 
 Prebulit `clang` will try to link to `libtinfo.so.5`. Depending on the host
-architecture, symlink to appropriate `libncurses`
+architecture, symlink to appropriate `libncurses`:
 
 ```bash
 $ sudo ln -s /usr/lib/libncurses.so.5 /usr/lib/libtinfo.so.5
@@ -123,7 +125,7 @@ $ sudo ln -s /usr/lib/libncurses.so.5 /usr/lib/libtinfo.so.5
 
 ## Tests
 
-Test your changes confirm to the project coding style using:
+Test your changes conform to the project coding style using:
 
 ```bash
 $ ./script/cpplint.py

docs/development/build-instructions-osx.md

@@ -1,17 +1,19 @@
-# Build instructions (Mac)
+# Build Instructions (OS X)
+
+Follow the guidelines below for building Electron on OS X.
 
 ## Prerequisites
 
 * OS X >= 10.8
 * [Xcode](https://developer.apple.com/technologies/tools/) >= 5.1
-* [node.js](http://nodejs.org) (external).
+* [node.js](http://nodejs.org) (external)
 
-If you are using the python downloaded by Homebrew, you also need to install
+If you are using the Python downloaded by Homebrew, you also need to install
 following python modules:
 
 * pyobjc
 
-## Getting the code
+## Getting the Code
 
 ```bash
 $ git clone https://github.com/atom/electron.git
@@ -20,7 +22,7 @@ $ git clone https://github.com/atom/electron.git
 ## Bootstrapping
 
 The bootstrap script will download all necessary build dependencies and create
-build project files. Notice that we're using `ninja` to build Electron so
+the build project files. Notice that we're using `ninja` to build Electron so
 there is no Xcode project generated.
 
 ```bash
@@ -44,14 +46,14 @@ $ ./script/build.py -c D
 
 After building is done, you can find `Electron.app` under `out/D`.
 
-## 32bit support
+## 32bit Support
 
-Electron can only be built for 64bit target on OS X, and there is no plan to
+Electron can only be built for a 64bit target on OS X and there is no plan to
 support 32bit OS X in future.
 
 ## Tests
 
-Test your changes confirm to the project coding style using:
+Test your changes conform to the project coding style using:
 
 ```bash
 $ ./script/cpplint.py

docs/development/build-instructions-windows.md

@@ -1,43 +1,44 @@
-# Build instructions (Windows)
+# Build Instructions (Windows)
+
+Follow the guidelines below for building Electron on Windows.
 
 ## Prerequisites
 
 * Windows 7 / Server 2008 R2 or higher
 * Visual Studio 2013 - [download VS 2013 Community Edition for
-  free](https://www.visualstudio.com/downloads/download-visual-studio-vs)
+  free](https://www.visualstudio.com/downloads/download-visual-studio-vs).
 * [Python 2.7](http://www.python.org/download/releases/2.7/)
 * [Node.js](http://nodejs.org/download/)
-* [git](http://git-scm.com)
+* [Git](http://git-scm.com)
 
-If you don't have a Windows installation at the moment,
+If you don't currently have a Windows installation, [modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads)
-[modern.ie](https://www.modern.ie/en-us/virtualization-tools#downloads) has
+has timebombed versions of Windows that you can use to build Electron.
-timebombed versions of Windows that you can use to build Electron.
 
-The building of Electron is done entirely with command-line scripts, so you
+Building Electron is done entirely with command-line scripts and cannot be done
-can use any editor you like to develop Electron, but it also means you can
+with Visual Studio. You can develop Electron with any editor but support for
-not use Visual Studio for the development. Support of building with Visual
+building with Visual Studio will come in the future.
-Studio will come in the future.
 
 **Note:** Even though Visual Studio is not used for building, it's still
 **required** because we need the build toolchains it provides.
 
-**Note:** Visual Studio 2015 will not work. Please make sure to get MSVS **2013**.
+**Note:** Visual Studio 2015 will not work. Please make sure to get MSVS
+**2013**.
 
-## Getting the code
+## Getting the Code
 
 ```powershell
-git clone https://github.com/atom/electron.git
+$ git clone https://github.com/atom/electron.git
 ```
 
 ## Bootstrapping
 
 The bootstrap script will download all necessary build dependencies and create
-build project files. Notice that we're using `ninja` to build Electron so
+the build project files. Notice that we're using `ninja` to build Electron so
 there is no Visual Studio project generated.
 
 ```powershell
-cd electron
+$ cd electron
-python script\bootstrap.py -v
+$ python script\bootstrap.py -v
 ```
 
 ## Building
@@ -45,50 +46,51 @@ python script\bootstrap.py -v
 Build both Release and Debug targets:
 
 ```powershell
-python script\build.py
+$ python script\build.py
 ```
 
 You can also only build the Debug target:
 
 ```powershell
-python script\build.py -c D
+$ python script\build.py -c D
 ```
 
 After building is done, you can find `electron.exe` under `out\D` (debug
 target) or under `out\R` (release target).
 
-## 64bit build
+## 64bit Build
 
 To build for the 64bit target, you need to pass `--target_arch=x64` when running
 the bootstrap script:
 
 ```powershell
-python script\bootstrap.py -v --target_arch=x64
+$ python script\bootstrap.py -v --target_arch=x64
 ```
 
 The other building steps are exactly the same.
 
 ## Tests
 
-Test your changes confirm to the project coding style using:
+Test your changes conform to the project coding style using:
 
 ```powershell
-python script\cpplint.py
+$ python script\cpplint.py
 ```
 
 Test functionality using:
 
 ```powershell
-python script\test.py
+$ python script\test.py
 ```
 
 Tests that include native modules (e.g. `runas`) can't be executed with the
-debug build (see #2558 for details), but they will work with the release build.
+debug build (see [#2558](https://github.com/atom/electron/issues/2558) for
+details), but they will work with the release build.
 
 To run the tests with the release build use:
 
 ```powershell
-python script\test.py -R
+$ python script\test.py -R
 ```
 
 ## Troubleshooting
@@ -122,24 +124,24 @@ Traceback (most recent call last):
 subprocess.CalledProcessError: Command '['npm.cmd', 'install']' returned non-zero exit status 3
 ```
 
-This is caused by a bug when using Cygwin python and Win32 node together. The
+This is caused by a bug when using Cygwin Python and Win32 Node together. The
-solution is to use the Win32 python to execute the bootstrap script (supposing
+solution is to use the Win32 Python to execute the bootstrap script (assuming
-you have installed python under `C:\Python27`):
+you have installed Python under `C:\Python27`):
 
-```bash
+```powershell
-/cygdrive/c/Python27/python.exe script/bootstrap.py
+$ /cygdrive/c/Python27/python.exe script/bootstrap.py
 ```
 
 ### LNK1181: cannot open input file 'kernel32.lib'
 
-Try reinstalling 32bit node.js.
+Try reinstalling 32bit Node.js.
 
 ### Error: ENOENT, stat 'C:\Users\USERNAME\AppData\Roaming\npm'
 
 Simply making that directory [should fix the problem](http://stackoverflow.com/a/25095327/102704):
 
 ```powershell
-mkdir ~\AppData\Roaming\npm
+$ mkdir ~\AppData\Roaming\npm
 ```
 
 ### node-gyp is not recognized as an internal or external command

docs/development/build-system-overview.md

@@ -1,71 +1,72 @@
-# Build system overview
+# Build System Overview
 
-Electron uses `gyp` for project generation, and `ninja` for building, project
+Electron uses `gyp` for project generation and `ninja` for building. Project
-configurations can be found in `.gyp` and `.gypi` files.
+configurations can be found in the `.gyp` and `.gypi` files.
 
-## Gyp files
+## Gyp Files
 
-Following `gyp` files contain the main rules of building Electron:
+Following `gyp` files contain the main rules for building Electron:
 
 * `atom.gyp` defines how Electron itself is built.
 * `common.gypi` adjusts the build configurations of Node to make it build
   together with Chromium.
-* `vendor/brightray/brightray.gyp` defines how `brightray` is built, and
+* `vendor/brightray/brightray.gyp` defines how `brightray` is built and
-  includes the default configurations of linking with Chromium.
+  includes the default configurations for linking with Chromium.
 * `vendor/brightray/brightray.gypi` includes general build configurations about
   building.
 
-## Component build
+## Component Build
 
-Since Chromium is quite a large project, the final linking stage would take
+Since Chromium is quite a large project, the final linking stage can take
-quite a few minutes, making it hard for development. In order to solve this,
+quite a few minutes, which makes it hard for development. In order to solve
-Chromium introduced the "component build", which builds each component as a
+this, Chromium introduced the "component build", which builds each component as
-separate shared library, making linking very quick but sacrificing file size
+a separate shared library, making linking very quick but sacrificing file size
 and performance.
 
 In Electron we took a very similar approach: for `Debug` builds, the binary
-will be linked to shared library version of Chromium's components to achieve
+will be linked to a shared library version of Chromium's components to achieve
 fast linking time; for `Release` builds, the binary will be linked to the static
 library versions, so we can have the best possible binary size and performance.
 
-## Minimal bootstrapping
+## Minimal Bootstrapping
 
-All of Chromium's prebuilt binaries(libchromiumcontent) are downloaded when
+All of Chromium's prebuilt binaries (`libchromiumcontent`) are downloaded when
 running the bootstrap script. By default both static libraries and shared
 libraries will be downloaded and the final size should be between 800MB and 2GB
-according to the platform.
+depending on the platform.
 
-By default, libchromiumcontent is downloaded from Amazon Web Services.
+By default, `libchromiumcontent` is downloaded from Amazon Web Services.
-If the `LIBCHROMIUMCONTENT_MIRROR` environment variable is set, bootrstrap
+If the `LIBCHROMIUMCONTENT_MIRROR` environment variable is set, the bootstrap
 script will download from it.
-[libchromiumcontent-qiniu-mirror](https://github.com/hokein/libchromiumcontent-qiniu-mirror)
+[`libchromiumcontent-qiniu-mirror`](https://github.com/hokein/libchromiumcontent-qiniu-mirror)
-is a mirror for libchromiumcontent. If you have trouble in accessing AWS, you can
+is a mirror for `libchromiumcontent`. If you have trouble in accessing AWS, you
-switch download address to it via `export LIBCHROMIUMCONTENT_MIRROR=http://7xk3d2.dl1.z0.glb.clouddn.com/`
+can switch the download address to it via
+`export LIBCHROMIUMCONTENT_MIRROR=http://7xk3d2.dl1.z0.glb.clouddn.com/`
 
 If you only want to build Electron quickly for testing or development, you
-can only download the shared library versions by passing the `--dev` parameter:
+can download just the shared library versions by passing the `--dev` parameter:
 
 ```bash
 $ ./script/bootstrap.py --dev
 $ ./script/build.py -c D
 ```
 
-## Two-phrase project generation
+## Two-Phrase Project Generation
 
 Electron links with different sets of libraries in `Release` and `Debug`
-builds, however `gyp` doesn't support configuring different link settings for
+builds. `gyp`, however, doesn't support configuring different link settings for
 different configurations.
 
 To work around this Electron uses a `gyp` variable
-`libchromiumcontent_component` to control which link settings to use, and only
+`libchromiumcontent_component` to control which link settings to use and only
 generates one target when running `gyp`.
 
-## Target names
+## Target Names
 
 Unlike most projects that use `Release` and `Debug` as target names, Electron
 uses `R` and `D` instead. This is because `gyp` randomly crashes if there is
-only one `Release` or `Debug` build configuration is defined, and Electron has
+only one `Release` or `Debug` build configuration defined, and Electron only has
-to only generate one target for one time as stated above.
+to generate one target at a time as stated above.
 
-This only affects developers, if you are only building Electron for rebranding
+This only affects developers, if you are just building Electron for rebranding
 you are not affected.

docs/development/coding-style.md

@@ -1,35 +1,37 @@
-# Coding style
+# Coding Style
+
+These are the style guidelines for coding in Electron.
 
 ## C++ and Python
 
-For C++ and Python, we just follow Chromium's [Coding
+For C++ and Python, we follow Chromium's [Coding
-Style](http://www.chromium.org/developers/coding-style), there is also a
+Style](http://www.chromium.org/developers/coding-style). There is also a
-script `script/cpplint.py` to check whether all files confirm.
+script `script/cpplint.py` to check whether all files conform.
 
-The python's version we are using now is Python 2.7.
+The Python version we are using now is Python 2.7.
 
 The C++ code uses a lot of Chromium's abstractions and types, so it's
 recommended to get acquainted with them. A good place to start is
-Chromium's [Important Abstractions and Data Structures]
+Chromium's [Important Abstractions and Data Structures](https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures)
-(https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures) 
 document. The document mentions some special types, scoped types (that
-automatically release their memory when going out of scope), logging mechanisms etc.
+automatically release their memory when going out of scope), logging mechanisms
+etc.
 
 ## CoffeeScript
 
 For CoffeeScript, we follow GitHub's [Style
-Guide](https://github.com/styleguide/javascript), and also following rules:
+Guide](https://github.com/styleguide/javascript) and the following rules:
 
 * Files should **NOT** end with new line, because we want to match Google's
   styles.
 * File names should be concatenated with `-` instead of `_`, e.g.
   `file-name.coffee` rather than `file_name.coffee`, because in
   [github/atom](https://github.com/github/atom) module names are usually in
-  the `module-name` form, this rule only applies to `.coffee` files.
+  the `module-name` form. This rule only applies to `.coffee` files.
 
 ## API Names
 
 When creating a new API, we should prefer getters and setters instead of
-jQuery's one-function style, for example, `.getText()` and `.setText(text)`
+jQuery's one-function style. For example, `.getText()` and `.setText(text)`
 are preferred to `.text([text])`. There is a
-[discussion](https://github.com/atom/electron/issues/46) of this.
+[discussion](https://github.com/atom/electron/issues/46) on this.

docs/development/setting-up-symbol-server.md

@@ -1,4 +1,4 @@
-# Setting up symbol server in debugger
+# Setting Up Symbol Server in Debugger
 
 Debug symbols allow you to have better debugging sessions. They have information
 about the functions contained in executables and dynamic libraries and provide
@@ -16,16 +16,16 @@ unoptimized local build.
 
 The official symbol server URL for Electron is
 http://54.249.141.255:8086/atom-shell/symbols.
-You cannot visit this URL directly: you must add it to the symbol path of your
+You cannot visit this URL directly, you must add it to the symbol path of your
 debugging tool. In the examples below, a local cache directory is used to avoid
 repeatedly fetching the PDB from the server. Replace `c:\code\symbols` with an
 appropriate cache directory on your machine.
 
-## Using the symbol server in Windbg
+## Using the Symbol Server in Windbg
 
 The Windbg symbol path is configured with a string value delimited with asterisk
 characters. To use only the Electron symbol server, add the following entry to
-your symbol path (__note:__ you can replace `c:\code\symbols` with any writable
+your symbol path (__Note:__ you can replace `c:\code\symbols` with any writable
 directory on your computer, if you'd prefer a different location for downloaded
 symbols):
 

docs/development/source-code-directory-structure.md

@@ -1,62 +1,63 @@
-# Source code directory structure
+# Source Code Directory Structure
 
-## Overview
+The source code of Electron is separated into a few parts, mostly
-
-The source code of Electron is separated into a few parts, and we are mostly
 following Chromium on the separation conventions.
 
 You may need to become familiar with [Chromium's multi-process
 architecture](http://dev.chromium.org/developers/design-documents/multi-process-architecture)
 to understand the source code better.
 
-## Structure of source code
+## Structure of Source Code
 
-* **atom** - Source code of Electron.
+```
-  * **app** - System entry code.
+Electron
-  * **browser** - The frontend including the main window, UI, and all of the
+├──atom - Source code of Electron.
-    main process things. This talks to the renderer to manage web pages.
+|  ├── app - System entry code.
-    * **lib** - Javascript part of the main process initialization code.
+|  ├── browser - The frontend including the main window, UI, and all of the
-    * **ui** - Implementation of UI stuff for different platforms.
+|  |   main process things. This talks to the renderer to manage web pages.
-      * **cocoa** - Cocoa specific source code.
+|  |   ├── lib - Javascript part of the main process initialization code.
-      * **gtk** - GTK+ specific source code.
+|  |   ├── ui - Implementation of UI stuff for different platforms.
-      * **win** - Windows GUI specific source code.
+|  |   |   ├── cocoa - Cocoa specific source code.
-    * **default_app** - The default page to show when Electron is started
+|  |   |   ├── gtk - GTK+ specific source code.
-      without providing an app.
+|  |   |   └── win - Windows GUI specific source code.
-    * **api** - The implementation of the main process APIs.
+|  |   ├── default_app - The default page to show when Electron is started
-       * **lib** - Javascript part of the API implementation.
+|  |   |   without providing an app.
-    * **net** - Network related code.
+|  |   ├── api - The implementation of the main process APIs.
-    * **mac** - Mac specific Objective-C source code.
+|  |   |   └── lib - Javascript part of the API implementation.
-    * **resources** - Icons, platform-dependent files, etc.
+|  |   ├── net - Network related code.
-  * **renderer** - Code that runs in renderer process.
+|  |   ├── mac - Mac specific Objective-C source code.
-    * **lib** - Javascript part of renderer initialization code.
+|  |   └── resources - Icons, platform-dependent files, etc.
-    * **api** - The implementation of renderer process APIs.
+|  ├── renderer - Code that runs in renderer process.
-       * **lib** - Javascript part of the API implementation.
+|  |   ├── lib - Javascript part of renderer initialization code.
-  * **common** - Code that used by both the main and renderer processes,
+|  |   └── api - The implementation of renderer process APIs.
-    including some utility functions and code to integrate node's message
+|  |       └── lib - Javascript part of the API implementation.
-    loop into Chromium's message loop.
+|  └── common - Code that used by both the main and renderer processes,
-    * **lib** - Common Javascript initialization code.
+|      including some utility functions and code to integrate node's message
-    * **api** - The implementation of common APIs, and foundations of
+|      loop into Chromium's message loop.
-    Electron's built-in modules.
+|      ├── lib - Common Javascript initialization code.
-       * **lib** - Javascript part of the API implementation.
+|      └── api - The implementation of common APIs, and foundations of
-* **chromium_src** - Source code that copied from Chromium.
+|          Electron's built-in modules.
-* **docs** - Documentations.
+|          └── lib - Javascript part of the API implementation.
-* **spec** - Automatic tests.
+├── chromium_src - Source code that copied from Chromium.
-* **atom.gyp** - Building rules of Electron.
+├── docs - Documentations.
-* **common.gypi** - Compiler specific settings and building rules for other
+├── spec - Automatic tests.
+├── atom.gyp - Building rules of Electron.
+└── common.gypi - Compiler specific settings and building rules for other
     components like `node` and `breakpad`.
+```
 
-## Structure of other directories
+## Structure of Other Directories
 
 * **script** - Scripts used for development purpose like building, packaging,
   testing, etc.
 * **tools** - Helper scripts used by gyp files, unlike `script`, scripts put
   here should never be invoked by users directly.
 * **vendor** - Source code of third party dependencies, we didn't use
-  `third_party` as name because it would confuse with the same directory in
+  `third_party` as name because it would confuse it with the same directory in
   Chromium's source code tree.
 * **node_modules** - Third party node modules used for building.
 * **out** - Temporary output directory of `ninja`.
 * **dist** - Temporary directory created by `script/create-dist.py` script
   when creating an distribution.
 * **external_binaries** - Downloaded binaries of third-party frameworks which
-  do not support to be built via `gyp`.
+  do not support building with `gyp`.