From d3569b623ccd593c9ef62fcaf0aba2711dc7fbfa Mon Sep 17 00:00:00 2001
From: James M Snell <jasnell@gmail.com>
Date: Mon, 5 Feb 2018 21:55:16 -0800
Subject: doc: remove **Note:** tags

Remove the various **Note:** prefixes throughout the docs.

PR-URL: https://github.com/nodejs/node/pull/18592
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
---
 doc/api/stream.md | 143 +++++++++++++++++++++++++++---------------------------
 1 file changed, 71 insertions(+), 72 deletions(-)

(limited to 'doc/api/stream.md')

diff --git a/doc/api/stream.md b/doc/api/stream.md
index 345e0d824d..023ba4d77b 100644
--- a/doc/api/stream.md
+++ b/doc/api/stream.md
@@ -188,8 +188,8 @@ Examples of [Writable][] streams include:
 * [child process stdin][]
 * [`process.stdout`][], [`process.stderr`][]
 
-*Note*: Some of these examples are actually [Duplex][] streams that implement
-the [Writable][] interface.
+Some of these examples are actually [Duplex][] streams that implement the
+[Writable][] interface.
 
 All [Writable][] streams implement the interface defined by the
 `stream.Writable` class.
@@ -270,7 +270,7 @@ added: v0.9.4
 The `'error'` event is emitted if an error occurred while writing or piping
 data. The listener callback is passed a single `Error` argument when called.
 
-*Note*: The stream is not closed when the `'error'` event is emitted.
+The stream is not closed when the `'error'` event is emitted.
 
 ##### Event: 'finish'
 <!-- YAML
@@ -589,15 +589,14 @@ until a mechanism for either consuming or ignoring that data is provided. If
 the consuming mechanism is disabled or taken away, the Readable will *attempt*
 to stop generating the data.
 
-*Note*: For backwards compatibility reasons, removing [`'data'`][] event
-handlers will **not** automatically pause the stream. Also, if there are piped
-destinations, then calling [`stream.pause()`][stream-pause] will not guarantee
-that the stream will *remain* paused once those destinations drain and ask for
-more data.
+For backwards compatibility reasons, removing [`'data'`][] event handlers will
+**not** automatically pause the stream. Also, if there are piped destinations,
+then calling [`stream.pause()`][stream-pause] will not guarantee that the
+stream will *remain* paused once those destinations drain and ask for more data.
 
-*Note*: If a [Readable][] is switched into flowing mode and there are no
-consumers available to handle the data, that data will be lost. This can occur,
-for instance, when the `readable.resume()` method is called without a listener
+If a [Readable][] is switched into flowing mode and there are no consumers
+available to handle the data, that data will be lost. This can occur, for
+instance, when the `readable.resume()` method is called without a listener
 attached to the `'data'` event, or when a `'data'` event handler is removed
 from the stream.
 
@@ -715,10 +714,10 @@ added: v0.9.4
 The `'end'` event is emitted when there is no more data to be consumed from
 the stream.
 
-*Note*: The `'end'` event **will not be emitted** unless the data is
-completely consumed. This can be accomplished by switching the stream into
-flowing mode, or by calling [`stream.read()`][stream-read] repeatedly until
-all data has been consumed.
+The `'end'` event **will not be emitted** unless the data is completely
+consumed. This can be accomplished by switching the stream into flowing mode,
+or by calling [`stream.read()`][stream-read] repeatedly until all data has been
+consumed.
 
 ```js
 const readable = getReadableStreamSomehow();
@@ -793,9 +792,9 @@ readable: null
 end
 ```
 
-*Note*: In general, the `readable.pipe()` and `'data'` event mechanisms are
-easier to understand than the `'readable'` event.
-However, handling `'readable'` might result in increased throughput.
+In general, the `readable.pipe()` and `'data'` event mechanisms are easier to
+understand than the `'readable'` event. However, handling `'readable'` might
+result in increased throughput.
 
 ##### readable.isPaused()
 <!-- YAML
@@ -897,9 +896,8 @@ processing, the Writable destination *is not closed* automatically. If an
 error occurs, it will be necessary to *manually* close each stream in order
 to prevent memory leaks.
 
-*Note*: The [`process.stderr`][] and [`process.stdout`][] Writable streams are
-never closed until the Node.js process exits, regardless of the specified
-options.
+The [`process.stderr`][] and [`process.stdout`][] Writable streams are never
+closed until the Node.js process exits, regardless of the specified options.
 
 ##### readable.readableHighWaterMark
 <!-- YAML
@@ -953,11 +951,11 @@ A Readable stream in object mode will always return a single item from
 a call to [`readable.read(size)`][stream-read], regardless of the value of the
 `size` argument.
 
-*Note*: If the `readable.read()` method returns a chunk of data, a `'data'`
-event will also be emitted.
+If the `readable.read()` method returns a chunk of data, a `'data'` event will
+also be emitted.
 
-*Note*: Calling [`stream.read([size])`][stream-read] after the [`'end'`][]
-event has been emitted will return `null`. No runtime error will be raised.
+Calling [`stream.read([size])`][stream-read] after the [`'end'`][] event has
+been emitted will return `null`. No runtime error will be raised.
 
 ##### readable.readableLength
 <!-- YAML
@@ -1070,8 +1068,8 @@ buffer. This is useful in certain situations where a stream is being consumed by
 code that needs to "un-consume" some amount of data that it has optimistically
 pulled out of the source, so that the data can be passed on to some other party.
 
-*Note*: The `stream.unshift(chunk)` method cannot be called after the
-[`'end'`][] event has been emitted or a runtime error will be thrown.
+The `stream.unshift(chunk)` method cannot be called after the [`'end'`][] event
+has been emitted or a runtime error will be thrown.
 
 Developers using `stream.unshift()` often should consider switching to
 use of a [Transform][] stream instead. See the [API for Stream Implementers][]
@@ -1113,14 +1111,14 @@ function parseHeader(stream, callback) {
 }
 ```
 
-*Note*: Unlike [`stream.push(chunk)`][stream-push], `stream.unshift(chunk)`
-will not end the reading process by resetting the internal reading state of the
-stream. This can cause unexpected results if `readable.unshift()` is called
-during a read (i.e. from within a [`stream._read()`][stream-_read]
-implementation on a custom stream). Following the call to `readable.unshift()`
-with an immediate [`stream.push('')`][stream-push] will reset the reading state
-appropriately, however it is best to simply avoid calling `readable.unshift()`
-while in the process of performing a read.
+Unlike [`stream.push(chunk)`][stream-push], `stream.unshift(chunk)` will not
+end the reading process by resetting the internal reading state of the stream.
+This can cause unexpected results if `readable.unshift()` is called during a
+read (i.e. from within a [`stream._read()`][stream-_read] implementation on a
+custom stream). Following the call to `readable.unshift()` with an immediate
+[`stream.push('')`][stream-push] will reset the reading state appropriately,
+however it is best to simply avoid calling `readable.unshift()` while in the
+process of performing a read.
 
 ##### readable.wrap(stream)
 <!-- YAML
@@ -1329,10 +1327,10 @@ on the type of stream being created, as detailed in the chart below:
   </tr>
 </table>
 
-*Note*: The implementation code for a stream should *never* call the "public"
-methods of a stream that are intended for use by consumers (as described in
-the [API for Stream Consumers][] section). Doing so may lead to adverse
-side effects in application code consuming the stream.
+The implementation code for a stream should *never* call the "public" methods
+of a stream that are intended for use by consumers (as described in the
+[API for Stream Consumers][] section). Doing so may lead to adverse side effects
+in application code consuming the stream.
 
 ### Simplified Construction
 <!-- YAML
@@ -1445,12 +1443,12 @@ All Writable stream implementations must provide a
 [`writable._write()`][stream-_write] method to send data to the underlying
 resource.
 
-*Note*: [Transform][] streams provide their own implementation of the
+[Transform][] streams provide their own implementation of the
 [`writable._write()`][stream-_write].
 
-*Note*: This function MUST NOT be called by application code directly. It
-should be implemented by child classes, and called by the internal Writable
-class methods only.
+This function MUST NOT be called by application code directly. It should be
+implemented by child classes, and called by the internal Writable class methods
+only.
 
 The `callback` method must be called to signal either that the write completed
 successfully or failed with an error. The first argument passed to the
@@ -1482,9 +1480,9 @@ user programs.
 * `callback` {Function} A callback function (optionally with an error
   argument) to be invoked when processing is complete for the supplied chunks.
 
-*Note*: This function MUST NOT be called by application code directly. It
-should be implemented by child classes, and called by the internal Writable
-class methods only.
+This function MUST NOT be called by application code directly. It should be
+implemented by child classes, and called by the internal Writable class methods
+only.
 
 The `writable._writev()` method may be implemented in addition to
 `writable._write()` in stream implementations that are capable of processing
@@ -1688,9 +1686,9 @@ changes:
 
 * `size` {number} Number of bytes to read asynchronously
 
-*Note*: This function MUST NOT be called by application code directly. It
-should be implemented by child classes, and called by the internal Readable
-class methods only.
+This function MUST NOT be called by application code directly. It should be
+implemented by child classes, and called by the internal Readable class methods
+only.
 
 All Readable stream implementations must provide an implementation of the
 `readable._read()` method to fetch data from the underlying resource.
@@ -1702,10 +1700,10 @@ from the resource and pushing data until `readable.push()` returns `false`. Only
 when `_read()` is called again after it has stopped should it resume pushing
 additional data onto the queue.
 
-*Note*: Once the `readable._read()` method has been called, it will not be
-called again until the [`readable.push()`][stream-push] method is called.
-`readable._read()` is guaranteed to be called only once within a
-synchronous execution, i.e. a microtick.
+Once the `readable._read()` method has been called, it will not be called again
+until the [`readable.push()`][stream-push] method is called. `readable._read()`
+is guaranteed to be called only once within a synchronous execution, i.e. a
+microtick.
 
 The `size` argument is advisory. For implementations where a "read" is a
 single operation that returns data can use the `size` argument to determine how
@@ -1794,7 +1792,8 @@ class SourceWrapper extends Readable {
   }
 }
 ```
-*Note*: The `readable.push()` method is intended be called only by Readable
+
+The `readable.push()` method is intended be called only by Readable
 Implementers, and only from within the `readable._read()` method.
 
 #### Errors While Reading
@@ -1860,10 +1859,10 @@ Because JavaScript does not have support for multiple inheritance, the
 `stream.Duplex` class is extended to implement a [Duplex][] stream (as opposed
 to extending the `stream.Readable` *and* `stream.Writable` classes).
 
-*Note*: The `stream.Duplex` class prototypically inherits from
-`stream.Readable` and parasitically from `stream.Writable`, but `instanceof`
-will work properly for both base classes due to overriding
-[`Symbol.hasInstance`][] on `stream.Writable`.
+The `stream.Duplex` class prototypically inherits from `stream.Readable` and
+parasitically from `stream.Writable`, but `instanceof` will work properly for
+both base classes due to overriding [`Symbol.hasInstance`][] on
+`stream.Writable`.
 
 Custom Duplex streams *must* call the `new stream.Duplex([options])`
 constructor and implement *both* the `readable._read()` and
@@ -2023,11 +2022,11 @@ A [Transform][] stream is a [Duplex][] stream where the output is computed
 in some way from the input. Examples include [zlib][] streams or [crypto][]
 streams that compress, encrypt, or decrypt data.
 
-*Note*: There is no requirement that the output be the same size as the input,
-the same number of chunks, or arrive at the same time. For example, a
-Hash stream will only ever have a single chunk of output which is
-provided when the input is ended. A `zlib` stream will produce output
-that is either much smaller or much larger than its input.
+There is no requirement that the output be the same size as the input, the same
+number of chunks, or arrive at the same time. For example, a Hash stream will
+only ever have a single chunk of output which is provided when the input is
+ended. A `zlib` stream will produce output that is either much smaller or much
+larger than its input.
 
 The `stream.Transform` class is extended to implement a [Transform][] stream.
 
@@ -2037,9 +2036,9 @@ methods. Custom Transform implementations *must* implement the
 [`transform._transform()`][stream-_transform] method and *may* also implement
 the [`transform._flush()`][stream-_flush] method.
 
-*Note*: Care must be taken when using Transform streams in that data written
-to the stream can cause the Writable side of the stream to become paused if
-the output on the Readable side is not consumed.
+Care must be taken when using Transform streams in that data written to the
+stream can cause the Writable side of the stream to become paused if the output
+on the Readable side is not consumed.
 
 #### new stream.Transform([options])
 
@@ -2103,9 +2102,9 @@ after all data has been output, which occurs after the callback in
 * `callback` {Function} A callback function (optionally with an error
   argument and data) to be called when remaining data has been flushed.
 
-*Note*: This function MUST NOT be called by application code directly. It
-should be implemented by child classes, and called by the internal Readable
-class methods only.
+This function MUST NOT be called by application code directly. It should be
+implemented by child classes, and called by the internal Readable class methods
+only.
 
 In some cases, a transform operation may need to emit an additional bit of
 data at the end of the stream. For example, a `zlib` compression stream will
@@ -2138,9 +2137,9 @@ user programs.
   argument and data) to be called after the supplied `chunk` has been
   processed.
 
-*Note*: This function MUST NOT be called by application code directly. It
-should be implemented by child classes, and called by the internal Readable
-class methods only.
+This function MUST NOT be called by application code directly. It should be
+implemented by child classes, and called by the internal Readable class methods
+only.
 
 All Transform stream implementations must provide a `_transform()`
 method to accept input and produce output. The `transform._transform()`
-- 
cgit v1.2.3