To verify a text editor preview described as updating about 0.3 seconds after editing, separate the documented value from an observed screen result. Hands-on checks confirmed only that a text tab and preview tab were associated and that the same text-to-preview relationship remained after reload. They did not verify 0.3-second rendering, five timed trials, preview-name following, or return from a preview selection to the source position.
This article designs a reader-run test with one 1,500-character chapter containing a heading, bold text, an image reference, a link, and one controlled word change. It does not report that this specimen completed an automatic refresh or source return. It also does not promise that every machine finishes at exactly 0.300 seconds or feels equally fast. EPUB export and Mac-to-Mac performance comparisons are outside the scope.
Decision: Separate verified link persistence from unverified refresh behavior
Create two separate fields. The first says “documented delay: approximately 0.3 seconds.” The second holds the observed update time. Call the moment the final key is released T0. Call the first moment the changed word is visible in the preview T1. The observed interval is T1 minus T0.
Exact agreement with 0.300 seconds would not be the acceptance condition in a future screen test. That test would require the changed item to appear without a manual refresh and a separate return to the same source position. The current hands-on result does not establish either behavior. If a measured interval is longer, record the conditions instead of summarizing the result as “slow.” Continued typing, a tab change, image loading, or a coarse timing method can represent different causes.
This separation recovers the title’s 0.3-second promise from the documented product behavior while avoiding an unmeasured claim about speed or feel.
Build a 1,500-character chapter around one source anchor
Name the test manuscript PREVIEW-359.md and place source anchor P359-07 near the middle. Include these four rendered elements:
- a heading named
Heading 359; - bold text named
Bold 359; - image syntax
; - link syntax
[Reference 359](references/preview-359.txt).
Immediately after the anchor, write “before update: blue door.” During the first trial, change “blue” to “white” and assign change ID EDIT-359-01. Do not change the heading, link, or image in the same trial. A one-item change makes the observed preview event unambiguous.
When running the proposed test, open the preview and confirm on screen that it follows the intended manuscript tab and shows “blue door” around P359-07. Call this baseline B0. That visible baseline was not checked in hands-on testing; a stored link ID is not a substitute for it.
Keep five timed updates as a reader-run test plan
If you run the test, change blue to white in the first trial and white to red in the second. Continue alternating the color word at the same location for five trials. Record trial ID, old word, new word, T0, T1, manual-refresh use, and the word that appeared in the preview. These five trials have not been run.
T0 is the final key release, not the first key in a multi-key edit. If the automatic refresh waits until typing pauses, timing from the first key would mix typing duration with the documented delay. T1 is the first frame or observation in which the changed word can be read, not the later moment when the whole screen feels settled.
Do not establish 0.3-second precision with a visual stopwatch alone. If a screen recording is used, keep the final input and word change in view and convert the frame difference into an observed interval. If the recording method is too coarse, mark the result “automatic refresh observed; timing approximate.” Keep all five values, their median, and their range instead of reporting only the fastest run.
Distinguish waiting from updated state
Call the period between T0 and the visible word change state W. Call the period after the new word appears state U. If another character is entered during W, stop that trial and establish a new T0. Otherwise, the recorded interval no longer represents the pause after the final input.
In U, verify that the heading, bold text, image reference, and link remain represented. Do not include image loading time in the text-update interval. The moment the changed word appears and the moment an image finishes drawing belong in different fields. Link correctness and EPUB conversion are also different tests.
If the preview does not change, check the source tab, unsaved edit, change ID, and final input time before using a manual refresh. A result corrected by a manual refresh does not pass the automatic-update check.
Keep source-position return as a separate unverified test
A visible update would be only half the editing loop. In a future test, select “white door” or “red door” in the updated preview and use the documented source-position return behavior. Verify that the cursor lands in PREVIEW-359.md at P359-07 with the changed word visible. This selection-to-source operation was not exercised in hands-on testing.
The return row should contain selected preview text, returned filename, returned anchor, nearby source characters, and result. If the cursor lands on another occurrence of “door,” record that duplicate wording prevented a unique return. Revise the specimen with a more distinctive phrase or anchor and repeat the trial.
Automatic refresh and source return are separate behaviors. A short T1 minus T0 does not pass if the return location is wrong. A correct return does not prove a 0.3-second automatic refresh if a manual reload was required.
Connect input, wait, display, and return on one row
Give every trial four result columns: input, wait, display, and return. One row might contain EDIT-359-03 red to white, T0, T1 plus “white door,” and PREVIEW-359.md / P359-07.
Stop the test if the changed word appears only after a manual refresh, the preview follows a different tab, or the selection returns to the wrong source occurrence. Do not rank speed after any of these failures. Repair the source association or specimen and repeat the same controlled change.
When all five trials complete the same route, report the observed median and range. Those numbers describe the test environment; they are not performance guarantees for every Mac.
Fix the timing resolution before the first trial. A clock that reports only whole seconds cannot distinguish an approximate 0.3-second interval, so use it only to record whether an automatic update occurred and mark timing as “insufficient resolution.” When frame counting is used, record the capture frame rate. Trials measured with a later, higher-resolution method belong to a separate group instead of being mixed into the original five.
The observed result stops at retained link IDs
A hands-on check linked a preview tab to a text tab and then closed and reopened the workspace. The preview tab still corresponded to the same text tab after reload. That result establishes stored tab association, not visible rendering, refresh timing, name following, or source-position return.
Current Rune Studio documentation describes an update about 0.3 seconds after an edit, preview content and name following a source-tab change, and return to source after preview text selection. Those documented functions justify the proposed test, but none of those screen behaviors was exercised here. They do not prove that five trials passed, that every update completes at exactly 0.300 seconds, or that an image finishes drawing in the same interval.
EPUB export and Mac-to-Mac performance comparisons remain outside this article.
Start by changing one word at P359-07
Place “blue door” at P359-07 in PREVIEW-359.md and confirm baseline B0. Change blue to white, mark the final input as T0, and record the first visible “white door” as T1. Then select the changed phrase in the preview and verify the return to P359-07. These are next test steps, not current verified results.
Approximately 0.3 seconds is a documented value. The current verified result ends at link-ID persistence after reload. An observed interval, manual-refresh field, name-following result, and returned position are still required before the title behavior can be reported as tested. If Rune Studio is a candidate, check the current Mac feature scope on the Rune Studio product page.
