Skip to content

AutoCorrect2 conflict checking

Use this workflow when candidate hotstrings already exist and need to be checked against the active hotstrings in a configured AutoCorrect2 project.

run_autocorrect2_check() accepts a sequence of AutoCorrect2CandidateHotstring objects:

Conflict Checking Workflow
flowchart TD
    A["Supplied candidates"] --> D["Resolve options and<br>assess conflicts"]
    B["Configured AutoCorrect2<br>source files"] --> C["Load existing<br>hotstrings"]
    C --> D
    D --> E["AutoCorrect2CheckResult"]

Typo generation is not involved. The returned AutoCorrect2CheckResult partitions the supplied candidates into accepted and rejected groups.

Each supplied candidate retains its semantic replacement and derives the AutoCorrect2-compatible AutoHotkey content used when it is rendered.

The pipeline can optionally append accepted candidates to the generated include file. The AutoCorrect2 writer owns the generated-file location and output policy, while generic filesystem operations remain in hotstring.file_io.

Command-line usage

Supply candidates directly by repeating --candidate:

uv run python -m hotstring autocorrect2-check `
    --candidate "teh" "the" "B0X" `
    --candidate "adn" "and" "B0X" `
    --project-dir "H:\Projects\AutoCorrect2" `
    --report .\reports\autocorrect2-check.txt

Each occurrence receives the semantic trigger, semantic replacement, and hotstring option string.

Alternatively, use --candidates-file with a UTF-8 JSON array:

[
  {
    "trigger": "teh",
    "replacement": "the",
    "options": "B0X"
  },
  {
    "trigger": "adn",
    "replacement": "and",
    "options": "B0X"
  }
]
uv run python -m hotstring autocorrect2-check `
    --candidates-file .\candidates.json

--candidate and --candidates-file are mutually exclusive. The command is read-only unless --write-accepted is supplied.

See also: Command-line interface for project-directory resolution and all command options.