edfcore 0.4.187 → 0.4.188

package/dist/constants.d.ts

@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
     readonly reserved: 224;
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export declare const VERSION = "0.4.187";
+export declare const VERSION = "0.4.188";
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.js

@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
     reserved: 224,
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.187';
+export const VERSION = '0.4.188';
 //# sourceMappingURL=constants.js.map

package/dist/recording.d.ts

@@ -13,8 +13,8 @@
  *   window that selects any records is a single element. If two shapes existed, consumers would
  *   write against the easy one and misbehave on EDF+D. A window entirely inside a gap, past the
  *   end, or of non-positive duration returns `[]` — the last two on a continuous file too, which
- *   the sentence above said could not happen. Nothing is ever filled in: there is no gap-fill and
- *   no gap-fill option.
+ *   is why the sentence above is about windows that select records and not about windows.
+ *   Nothing is ever filled in: there is no gap-fill and no gap-fill option.
  * - Chunks stay RECORD-ALIGNED and are therefore usually wider than the window asked for. The
  *   exact per-signal narrowing is `trimToWindow`, which is pure and testable without I/O.
  *

package/dist/recording.js

@@ -13,8 +13,8 @@
  *   window that selects any records is a single element. If two shapes existed, consumers would
  *   write against the easy one and misbehave on EDF+D. A window entirely inside a gap, past the
  *   end, or of non-positive duration returns `[]` — the last two on a continuous file too, which
- *   the sentence above said could not happen. Nothing is ever filled in: there is no gap-fill and
- *   no gap-fill option.
+ *   is why the sentence above is about windows that select records and not about windows.
+ *   Nothing is ever filled in: there is no gap-fill and no gap-fill option.
  * - Chunks stay RECORD-ALIGNED and are therefore usually wider than the window asked for. The
  *   exact per-signal narrowing is `trimToWindow`, which is pure and testable without I/O.
  *

package/docs/CHANGELOG.md

@@ -6,6 +6,14 @@ alone does not tell you whether you were affected.
 edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
 defect; those are called out below.
 
+## 0.4.188
+
+- **Corrected** the `readWindow` docblock, which told the reader the sentence above it "said could
+  not happen" about something that sentence no longer says. It did before 5f88404: the array
+  "always has one element" on a continuous file. That commit both fixed the sentence and added the
+  clause pointing back at it, so the accusation was false in the commit that shipped it. It now
+  gives the reason the qualifier is there instead.
+
 ## 0.4.187
 
 - **Corrected** the `FormatHeaderOptions` docblock, which opened "There is one, and it is opt-IN".

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.4.187",
+  "version": "0.4.188",
   "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
   "keywords": [
     "edf",

package/src/constants.ts

@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
 } as const;
 
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.187';
+export const VERSION = '0.4.188';

package/src/recording.ts

@@ -13,8 +13,8 @@
  *   window that selects any records is a single element. If two shapes existed, consumers would
  *   write against the easy one and misbehave on EDF+D. A window entirely inside a gap, past the
  *   end, or of non-positive duration returns `[]` — the last two on a continuous file too, which
- *   the sentence above said could not happen. Nothing is ever filled in: there is no gap-fill and
- *   no gap-fill option.
+ *   is why the sentence above is about windows that select records and not about windows.
+ *   Nothing is ever filled in: there is no gap-fill and no gap-fill option.
  * - Chunks stay RECORD-ALIGNED and are therefore usually wider than the window asked for. The
  *   exact per-signal narrowing is `trimToWindow`, which is pure and testable without I/O.
  *