doc: edit for concision

doc/api/async_hooks.md

@@ -484,9 +484,8 @@ fs.open(path, 'r', (err, fd) => {
 });
 ```
 
-It is important to note that the ID returned fom `executionAsyncId()` is related
-to execution timing, not causality (which is covered by `triggerAsyncId()`). For
-example:
+The ID returned fom `executionAsyncId()` is related to execution timing, not
+causality (which is covered by `triggerAsyncId()`). For example:
 
 ```js
 const server = net.createServer(function onConnection(conn) {
@@ -538,9 +537,8 @@ own resources.
 
 The `init` hook will trigger when an `AsyncResource` is instantiated.
 
-*Note*: It is important that `before`/`after` calls are unwound
-in the same order they are called. Otherwise an unrecoverable exception
-will occur and the process will abort.
+`before` and `after` calls are unwound in the same order they are called.
+Otherwise, an unrecoverable exception will occur and the process will abort.
 
 The following is an overview of the `AsyncResource` API.
 

doc/api/errors.md

@@ -312,11 +312,10 @@ location information will be displayed for that frame. Otherwise, the
 determined function name will be displayed with location information appended
 in parentheses.
 
-It is important to note that frames are **only** generated for JavaScript
-functions. If, for example, execution synchronously passes through a C++ addon
-function called `cheetahify`, which itself calls a JavaScript function, the
-frame representing the `cheetahify` call will **not** be present in the stack
-traces:
+Frames are only generated for JavaScript functions. If, for example, execution
+synchronously passes through a C++ addon function called `cheetahify` which
+itself calls a JavaScript function, the frame representing the `cheetahify` call
+will not be present in the stack traces:
 
 ```js
 const cheetahify = require('./native-binding.node');

doc/api/process.md

@@ -374,48 +374,55 @@ process.on('SIGINT', handle);
 process.on('SIGTERM', handle);
 ```
 
-*Note*: An easy way to send the `SIGINT` signal is with `<Ctrl>-C` in most
-terminal programs.
-
-It is important to take note of the following:
-
-* `SIGUSR1` is reserved by Node.js to start the [debugger][]. It's possible to
-  install a listener but doing so will _not_ stop the debugger from starting.
-* `SIGTERM` and `SIGINT` have default handlers on non-Windows platforms that
-  resets the terminal mode before exiting with code `128 + signal number`. If
-  one of these signals has a listener installed, its default behavior will be
-  removed (Node.js will no longer exit).
-* `SIGPIPE` is ignored by default. It can have a listener installed.
-* `SIGHUP` is generated on Windows when the console window is closed, and on
-  other platforms under various similar conditions, see signal(7). It can have a
-  listener installed, however Node.js will be unconditionally terminated by
-  Windows about 10 seconds later. On non-Windows platforms, the default
-  behavior of `SIGHUP` is to terminate Node.js, but once a listener has been
-  installed its default behavior will be removed.
-* `SIGTERM` is not supported on Windows, it can be listened on.
-* `SIGINT` from the terminal is supported on all platforms, and can usually be
-  generated with `CTRL+C` (though this may be configurable). It is not generated
-  when terminal raw mode is enabled.
-* `SIGBREAK` is delivered on Windows when `<Ctrl>+<Break>` is pressed, on
-  non-Windows platforms it can be listened on, but there is no way to send or
-  generate it.
-* `SIGWINCH` is delivered when the console has been resized. On Windows, this
-  will only happen on write to the console when the cursor is being moved, or
-  when a readable tty is used in raw mode.
-* `SIGKILL` cannot have a listener installed, it will unconditionally terminate
-  Node.js on all platforms.
-* `SIGSTOP` cannot have a listener installed.
-* `SIGBUS`, `SIGFPE`, `SIGSEGV` and `SIGILL`, when not raised artificially
-   using kill(2), inherently leave the process in a state from which it is not
-   safe to attempt to call JS listeners. Doing so might lead to the process
-   hanging in an endless loop, since listeners attached using `process.on()` are
-   called asynchronously and therefore unable to correct the underlying problem.
-
-*Note*: Windows does not support sending signals, but Node.js offers some
-emulation with [`process.kill()`][], and [`subprocess.kill()`][]. Sending
-signal `0` can be used to test for the existence of a process. Sending `SIGINT`,
-`SIGTERM`, and `SIGKILL` cause the unconditional termination of the target
-process.
+An easy way to send the `SIGINT` signal is with `<Ctrl>-C` in most terminal
+programs.
+
+`SIGUSR1` is reserved by Node.js to start the [debugger][]. It's possible to
+install a listener but doing so will _not_ stop the debugger from starting.
+
+`SIGTERM` and `SIGINT` have default handlers on non-Windows platforms that
+resets the terminal mode before exiting with code `128 + signal number`. If
+one of these signals has a listener installed, its default behavior will be
+removed (Node.js will no longer exit).
+
+`SIGPIPE` is ignored by default. It can have a listener installed.
+
+`SIGHUP` is generated on Windows when the console window is closed, and on
+other platforms under various similar conditions, see signal(7). It can have a
+listener installed, however Node.js will be unconditionally terminated by
+Windows about 10 seconds later. On non-Windows platforms, the default
+behavior of `SIGHUP` is to terminate Node.js, but once a listener has been
+installed its default behavior will be removed.
+
+`SIGTERM` is not supported on Windows, it can be listened on.
+
+`SIGINT` from the terminal is supported on all platforms, and can usually be
+generated with `CTRL+C` (though this may be configurable). It is not generated
+when terminal raw mode is enabled.
+
+`SIGBREAK` is delivered on Windows when `<Ctrl>+<Break>` is pressed, on
+non-Windows platforms it can be listened on, but there is no way to send or
+generate it.
+
+`SIGWINCH` is delivered when the console has been resized. On Windows, this
+will only happen on write to the console when the cursor is being moved, or
+when a readable tty is used in raw mode.
+
+`SIGKILL` cannot have a listener installed, it will unconditionally terminate
+Node.js on all platforms.
+
+`SIGSTOP` cannot have a listener installed.
+
+`SIGBUS`, `SIGFPE`, `SIGSEGV` and `SIGILL`, when not raised artificially
+using kill(2), inherently leave the process in a state from which it is not
+safe to attempt to call JS listeners. Doing so might lead to the process
+hanging in an endless loop, since listeners attached using `process.on()` are
+called asynchronously and therefore unable to correct the underlying problem.
+
+Windows does not support sending signals, but Node.js offers some emulation with
+[`process.kill()`][], and [`subprocess.kill()`][]. Sending signal `0` can be
+used to test for the existence of a process. Sending `SIGINT`, `SIGTERM`, and
+`SIGKILL` cause the unconditional termination of the target process.
 
 ## process.abort()
 <!-- YAML
@@ -677,9 +684,9 @@ If there are specific reasons to use `process.dlopen()` (for instance,
 to specify dlopen flags), it's often useful to use [`require.resolve()`][]
 to look up the module's path.
 
-*Note*: An important drawback when calling `process.dlopen()` is that the
-`module` instance must be passed. Functions exported by the C++ Addon will
-be accessible via `module.exports`.
+An important drawback when calling `process.dlopen()` is that the `module`
+instance must be passed. Functions exported by the C++ Addon will be accessible
+via `module.exports`.
 
 The example below shows how to load a C++ Addon, named as `binding`,
 that exports a `foo` function. All the symbols will be loaded before
@@ -987,10 +994,10 @@ process.exit(1);
 
 The shell that executed Node.js should see the exit code as `1`.
 
-It is important to note that calling `process.exit()` will force the process to
-exit as quickly as possible *even if there are still asynchronous operations
-pending* that have not yet completed fully, *including* I/O operations to
-`process.stdout` and `process.stderr`.
+Calling `process.exit()` will force the process to exit as quickly as possible
+even if there are still asynchronous operations pending that have not yet
+completed fully, including I/O operations to `process.stdout` and
+`process.stderr`.
 
 In most situations, it is not actually necessary to call `process.exit()`
 explicitly. The Node.js process will exit on its own *if there is no additional

doc/api/repl.md

@@ -114,9 +114,8 @@ $ node repl_test.js
 'message'
 ```
 
-It is important to note that context properties are *not* read-only by default.
-To specify read-only globals, context properties must be defined using
-`Object.defineProperty()`:
+Context properties are not read-only by default. To specify read-only globals,
+context properties must be defined using `Object.defineProperty()`:
 
 ```js
 const repl = require('repl');

doc/api/stream.md

@@ -1426,12 +1426,11 @@ successfully or failed with an error. The first argument passed to the
 `callback` must be the `Error` object if the call failed or `null` if the
 write succeeded.
 
-It is important to note that all calls to `writable.write()` that occur between
-the time `writable._write()` is called and the `callback` is called will cause
-the written data to be buffered. Once the `callback` is invoked, the stream will
-emit a [`'drain'`][] event. If a stream implementation is capable of processing
-multiple chunks of data at once, the `writable._writev()` method should be
-implemented.
+All calls to `writable.write()` that occur between the time `writable._write()`
+is called and the `callback` is called will cause the written data to be
+buffered. Once the `callback` is invoked, the stream will emit a [`'drain'`][]
+event. If a stream implementation is capable of processing multiple chunks of
+data at once, the `writable._writev()` method should be implemented.
 
 If the `decodeStrings` property is set in the constructor options, then
 `chunk` may be a string rather than a Buffer, and `encoding` will

doc/api/vm.md

@@ -87,9 +87,8 @@ changes:
     depending on whether code cache data is produced successfully.
 
 Creating a new `vm.Script` object compiles `code` but does not run it. The
-compiled `vm.Script` can be run later multiple times. It is important to note
-that the `code` is not bound to any global object; rather, it is bound before
-each run, just for that run.
+compiled `vm.Script` can be run later multiple times. The `code` is not bound to
+any global object; rather, it is bound before each run, just for that run.
 
 ### script.runInContext(contextifiedSandbox[, options])
 <!-- YAML