Before choosing a recommended Mac text editor for encoding safety, design a verification plan that can expose a candidate which writes through an unresolved warning. This article does not produce a candidate result. It produces one plan sheet that fixes a disposable input, four write paths, two on-disk measurements, and a forced-rejection rule.
None of the four routes has been run for this article. “Blocked,” “written,” and “rejected” are therefore future result labels, not measured findings. Multi-format and BOM comparison, replacement-character approval, completed conversion, and reopen testing remain separate work.
Put the forced-rejection rule at the top of the plan
Scoring warning design or feature count first can hide the one event the test is meant to expose: a disk write while the character remains unresolved. The plan therefore begins with this rule: if any route changes the disposable file on disk, remove that candidate from the encoding-safety shortlist.
An unrun route is not a pass. Fix the result vocabulary at BLOCK_OBSERVED, WRITE_OBSERVED, and UNTESTED. Every row remains UNTESTED until the four routes are actually executed. Reading this plan does not advance any candidate.
Design one disposable save trap
Define a disposable file rather than using a working manuscript. The planned input contains one character whose absence from the target encoding has been established separately and a visible line identifying the file as test material. The plan requires a fresh copy for every candidate and every write route.
Choose two baseline properties from modification time, byte count, and checksum. Record in advance which values will be captured, when they will be captured, and which on-disk copy they will be compared with. A visible warning alone will not count as blocking; the future result must use the disk state.
Define the unresolved starting state
The planned starting state retains the test character, does not substitute another character, and does not change the target encoding. Because warning position and wording can differ, the sheet includes a field for whether an unresolved state was observable.
No visible warning does not imply safety. The candidate may have missed the issue or may permit an unannounced write. Leave the route UNTESTED unless the operation is performed, and record WRITE_OBSERVED only when the measured disk evidence supports it.
Give each write path its own row
Create four rows: manual Save, the configured autosave trigger, window close, and application quit. Each future operation starts from the same defined state in a fresh copy. Reusing a copy changed by an earlier route would make the responsible writer ambiguous.
| Route | Planned starting state | Evidence to collect later | Current state |
|---|---|---|---|
| Manual Save | fresh copy with the issue unresolved | on-disk values before and after | UNTESTED |
| Autosave | fresh copy after its trigger is identified | on-disk values around one trigger | UNTESTED |
| Window close | fresh copy with the issue unresolved | choices shown and on-disk values | UNTESTED |
| Application quit | fresh copy with the issue unresolved | choices shown and on-disk values | UNTESTED |
The manual-Save row plans a save request while the warning remains. The autosave row requires its trigger to be identified before it is caused once. The close and quit rows also reserve fields for cancel, discard, or return choices. These are operation specifications for a later Stage 4 run, not verified actions in the current article.
Do not average away one write
The future decision rule marks any WRITE_OBSERVED row as a forced rejection and any remaining UNTESTED row as a hold. Only four measured BLOCK_OBSERVED rows would allow a candidate to proceed beyond this narrow stop test.
For example, a candidate would be rejected if manual Save blocked but autosave changed the disk values. It would remain on hold if Save and autosave blocked but window close was not run. These are hypothetical readings of the sheet, not measured results for candidates A, B, C, or Rune Studio.
Rune Studio has documentation evidence for inclusion in the plan
Rune Studio documentation lists detection of major Japanese encodings. It separately documents a product-specific red indication for unconvertible characters and a product-specific process that stops autosave until they are resolved. The claim ledger separates existing-encoding support from the product-specific presentation and process.
All of this is Stage 1 documentation evidence. It is not evidence of the current screen and not a Stage 4 operation from warning creation through an unchanged disk result. Rune Studio can therefore be entered in the plan as a candidate to test, but it has not passed the four routes and is not confirmed here as an encoding-safe recommendation.
Leave multi-format selection and manuscript repair elsewhere
STUDIO-029 compares candidates across BOM and source-format variants through edit, save-as, and reopen. STUDIO-065 uses an already selected environment to approve a replacement in one manuscript and complete a safe save.
This article produces the unexecuted verification plan that precedes both jobs. It approves no replacement, completes no conversion, and assigns no candidate result. The completed four-row sheet is handed to a later operation owner.
Conclusion: plan all four routes before judging a candidate
Before choosing a recommended Mac text editor for encoding safety, fix one unresolved character, four write routes, two on-disk measurements, and one forced-rejection rule. Give every route a fresh copy and initialize every result as UNTESTED.
The outcome of this article is an execution-ready plan, not a pass or rejection. Candidate selection can begin only after a separate Stage 4 run completes all four routes and records the evidence.
