A temporary highlight and a persistent term list answer different editing questions. When you select a word such as “however,” you may only want to inspect repetition in the paragraph you are revising. When you register a former character name or a prohibited expression, you want that term watched throughout the manuscript. Treating both marks as the same signal makes it easy to forget why a word was colored in the first place.
This guide builds a text editor color selected registered terms workflow around three separate kinds of evidence. A command-line check can prove that a list and its words were stored and activated. Public Rune documentation can describe the intended highlighting behavior. Only a visual check on the reader’s own screen can establish how the colors actually appear in that environment. Keeping those layers apart makes the result useful without claiming more than the test observed.
Give temporary and persistent marks different jobs
Before choosing colors, make a two-column note. Put words that matter only during the current pass in “selected now.” Put spellings, names, and warnings that must remain visible across chapters in “registered throughout.” This small decision prevents a persistent list from becoming a dump of every word that looked interesting once.
Rune’s published documentation says that selecting a string highlights matching strings after about 0.3 seconds. It also says that words in the active custom list are highlighted automatically and that highlight color and opacity can be adjusted. Those statements describe the product’s documented behavior. They do not tell us what a specific theme, display, or accessibility setting will look like.
The command-line test did not measure rendered colors. It also did not establish which mark wins when a selected string and a registered term occupy the same text. Therefore, this article does not promise that the two cases always use visibly different colors or that one layer always appears above the other. Those are visual questions reserved for the user check below.
The CLI test proved the list state, not the pixels
The test started with rune highlight create --name Evidence-STUDIO-315-1788369720 --json. Two highlight add-word --index 1 commands added sample word A and sample word B. Then rune highlight activate --index 1 made that list active. A JSON list readback reported activeIndex: 1 and both registered words.
Next, word A was removed. The following readback contained word B but no word A. Finally, the test deactivated and deleted the temporary list. The last list result contained only the default list and reported activeIndex: -1. All of those commands exited successfully.
This sequence has a precise contract. Its inputs are the unique list name, two sample words, and list index 1. Failure means that the active index or word set cannot be read back as expected. Recovery means reading the list first, deactivating or deleting an unintended temporary list, and recreating it under a unique name. Acceptance requires the two-word state, the one-word state after removal, and the clean default state to appear in that order. None of those checks is a substitute for looking at the screen.
Use a tiny copy to perform the visual check
Do not experiment on the only copy of a long manuscript. Open a short duplicate containing the same sample word twice. First, leave the custom list inactive, select one occurrence, wait at least 0.3 seconds, and inspect the other occurrence. Clear the selection. Then activate the temporary list and inspect the registered-word display. Finally, use the same string as both the selected and registered term and record what the overlap looks like.
Record the Rune version, operating system, theme, chosen color, opacity, and waiting time. Note whether the second occurrence was distinguishable in each phase. If the overlap is hard to interpret, do not label that visual result as a general Rune rule; it is an observation for that setup. A future product version or another theme may differ.
This checklist deliberately stops short of reporting a result. No graphical session was observed for this revision. The user performs the steps and supplies the result. That boundary is especially important for accessibility: two technically different colors may still be difficult to distinguish on a particular screen. Pair color with list names, written reasons, and search counts instead of making color the only signal.
Diagnose missing marks from stored state outward
If a registered word does not appear, first run the list readback. Confirm the expected list name, word spelling, and active index. Common mistakes include adding a word without activating its list, editing a different numeric index, or testing a spelling with different spaces or punctuation. These are state problems and can be resolved before changing the display settings.
If the state is wrong, deactivate the unintended list, remove it if it was created only for the test, and recreate a uniquely named list. If the state is correct, move outward to the sample document, the current theme, color, opacity, and delay. Keep the CLI result and the visual result in separate rows. This makes recovery repeatable and prevents a display symptom from being misreported as lost data.
The inverse mistake is also possible: a visible selected-word mark may be mistaken for proof that the persistent list is active. Clear the selection and read the active index before accepting that conclusion. Each signal should have one cause and one check.
Plan for the documented large-document boundary
Rune documentation states that same-word and registered-term highlighting stops for documents above 300,000 characters. When marks disappear in a very large file, do not immediately rebuild the term list. Check the document size and repeat the visual test in a chapter-sized copy.
That limit is a reason to avoid treating highlights as a publication gate by themselves. Use persistent colors as an early-warning layer, then search the manuscript and consult a written checklist before release. A missing color does not prove that a warning term is absent, especially when the document is near or beyond the documented threshold.
For long projects, keep the registered list small enough to remain meaningful. Group chapters into manageable files, give each warning term a short reason, and remove obsolete entries after the naming or terminology decision is settled. The color system then remains an editing aid rather than becoming another source of noise.
Accept the workflow only when every signal has a meaning
The final record should identify the purpose of the selected term, the purpose of each registered term, the stored list state, the user’s visual observation, and the cleanup state. Accept the workflow when the roles can be explained, the A/B additions and A removal can be read back, the short-copy display has been checked on the actual system, and the temporary list has been removed.
The text editor color selected registered terms approach is therefore less about decorating a manuscript than about preserving intent. A temporary mark asks, “Where else is this word near my current edit?” A registered mark asks, “Where does this known term still occur?” When every color answers only one of those questions, the author can revise with less guesswork and can explain the evidence behind each decision.