`selection-word-chars` doesn't parse escapes (e.g. `\t`) properly

[pluiedev]

Discussed in #10507

^{Originally posted by injust January 31, 2026}

Issue Description

If selection-word-chars is configured and includes \t, \ and t are used as word boundaries.

Because \t is in the default value of selection-word-chars, this means that configuring selection-word-chars (e.g. adding or removing boundary characters) will almost certainly result in broken word selection.

Expected Behavior

The selection-word-chars config option should correctly parse \t as the tab character.

Actual Behavior

\t in the value of selection-word-chars is parsed as literally \ and t.

Reproduction Steps

1. Open Ghostty
2. Run any command that produces output
3. Double-click any word that contains a t

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-main+89d3ad2bf

Version
  - version: 1.3.0-main+89d3ad2bf
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS Sequoia 15.7.3

Minimal Ghostty Configuration

# Just set it to the default value
selection-word-chars = " \t'\"│`|:;,()[]{}<>$"

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

---

Note: We should just reuse the string escape functions as defined by the Zig compiler in std.zig before compiling the list of codepoints. The test is supposed to catch this but it appears it never did...?