feat(macos): set-input-source and input-source-is

[alenkimov]

Describe your changes. Use imperative present tense.

Add native macOS input-source support.

• Add (set-input-source "...") to switch the current macOS keyboard input source by exact input source ID.
• Add (input-source-is "...") for switch conditions that check the current macOS keyboard input source by exact ID.
• Execute macOS Text Input Source Services calls through a per-user kanata-input-source-helper LaunchAgent so input-source operations run in the logged-in Aqua user session.
• Add a sample LaunchAgent plist and a minimal macOS input-source config sample.
• Document setup, config syntax, and the helper/session model.

This code was written entirely by Codex and needs careful maintainer review.

One practical use case for this is deterministic language selection on macOS via tap dance.

For example:

• 1 tap -> force US
• 2 taps -> force Russian

This is different from sending the system “next input source” shortcut, because that shortcut is stateful and depends on the current macOS source ordering. With set-input-source, the mapping is exact and deterministic.

I’m already using this pattern in my own Kanata config:
https://github.com/alenkimov/moonlander_msklc/blob/835fdf1c10b238c9f0c5733ff90ef4ec0768adab/MacOS/kanata.kbd#L19

Relevant part:

• us -> (set-input-source "com.apple.keylayout.US") + (layer-switch us)
• ru -> (set-input-source "com.apple.keylayout.RussianWin") + (layer-switch ru)
• toggle-lang -> (tap-dance-eager 250 (@us @ru))

Checklist

• Add documentation to docs/config.adoc
  • Yes or N/A
• Add example and basic docs to cfg_samples/kanata.kbd
  • Yes or N/A
• Update error messages
  • Yes or N/A
• Added tests, or did manual testing
  • Yes

Manual/testing notes:

• Ran cargo check.
• Ran cargo fmt --all -- --check.
• Ran cargo test -p kanata-parser parse_macos_input_source_support -- --nocapture.
• Ran workspace tests locally.
• Tested manually on macOS with com.apple.keylayout.US and com.apple.keylayout.RussianWin.

[jtroo]

To start, this is not something I like to see:

This code was written entirely by Codex and needs careful maintainer review.

The bar for contributions must be higher than this. There is no LLM policy defined in kanata but the one by Oxide looks like a reasonable one, if not too lengthy for the scope of this project. A relevant snippet:

Wherever LLM-generated code is used, it becomes the responsibility of the engineer. As part of this process of taking responsibility, self-review becomes essential: LLM-generated code should not be reviewed by others if the responsible engineer has not themselves reviewed it.

---

Onto the code itself, this PR does not look like something that feels worth the maintenance burden and is hyper-specific on the use case.

There are two separate design ideas here that could be worth exploring more but not worth pushing in their current use-case-constrained implementation further:

1. A more expressive alternative to push-msg with a synchronous request-response semantics and fork/switch-like evaluation based on the return value, to help support this input-source-helper integration better
2. more power switch conditionals, such as evaluating the results of TCP requests (similar to above) or of cmd executions