fix(config): stop forcing ascii_mode in VSCode

[JeremyLiu858]

Summary

• drop app_options/com.microsoft.VSCode/ascii_mode: true from data/squirrel.yaml
• document in place why it is gone and how to restore it
• no other app_options entry is touched

Motivation

This entry was uncommented in bdf1114 (2017-09-22, "chore(config): ascii mode in code editors")
as part of a batch that also enabled Xcode, TextWrangler, TextMate, Atom, Sublime Text 2, Aquamacs
and Emacs. It had been added commented-out a month earlier in fc61f85. Neither commit references an
issue or gives a rationale beyond the subject line, and VSCode was never evaluated on its own — the
premise was simply that code editors are for writing code. In 2017 that was true of VSCode 1.16.

It is no longer true. VSCode today hosts extension webview chat boxes (Copilot Chat, Claude Code,
Cline, Continue), SCM commit messages, comment threads, Markdown and plaintext editing — all
ordinary Chinese-input surfaces.

Crucially, the option cannot be scoped to the editor pane. IMKInputController is allocated per
bundle identifier, so updateAppOptions() applies ascii_mode to one rime session that covers the
entire application, webviews included.

Why this is so hard for users to diagnose

ascii_mode is absent from switcher/save_options, while schemas declare ascii_mode: reset: 0.
The option therefore re-arms on every new session, not once. A user who has remapped
ascii_composer/switch_key away from the defaults — a very common customisation — is left with no
ordinary key to escape ASCII mode inside VSCode.

The symptom that produces is "Squirrel cannot type Chinese in VSCode at all, but macOS's built-in
IME can". Because app_options is a Rime-only concept, Apple's IME is structurally immune, and
that asymmetry sends users looking for the cause anywhere except a config default:

Issue	State
#141	open	VSCode 配置 ascii_mode 无效
#264	closed	升级后 VSCode 中无法输入中文
#566	open	切换到鼠须管之后会自动变成英文模式
#987	open	鼠须管，在 vscode 中无法输入中文
#1027	closed	duplicate of #987
#1076	open	the documented workaround appears not to work

The reporter of #987 ticked the box "换用macOS系统自带输入法，可以输入中文" — the exact asymmetry.
See also #584, where the reporter discovered
app_options only by accident: "好家伙, 原来不是bug, 是默认给关闭掉了", and 14 commenters thanked
them for it. #1076 is worth a look too: that user did apply the documented patch, but put it in
default.custom.yaml, where app_options is silently ignored because it belongs to squirrel.yaml.

Measurement

macOS 26.4.1, Squirrel 1.1.2, luna_pinyin, typing into a VSCode extension webview.
Counting InputMethodKit activity in the unified log
(log show --predicate 'process == "Squirrel"' --info --debug):

	Setting marked text	Inserting text
before (23 keystrokes)	1	0
after ascii_mode: false + deploy	40	27

Before the change, rime composed nothing at all. The single Setting marked text is an artifact of
the first keystroke only: selRange starts as NSRange(NSNotFound, 0), so show()'s cache misses
once and then matches forever while the preedit stays empty.

Impact

What changes. VSCode sessions now start in the schema's default mode like every other
application, instead of being forced to ASCII.

Users who prefer ASCII in VSCode press their normal Chinese/English switch key, exactly as they
already do everywhere else — or restore the old behaviour explicitly:

# squirrel.custom.yaml
patch:
  app_options/com.microsoft.VSCode/ascii_mode: true

Users who already patched ascii_mode: false are unaffected; their patch becomes a harmless
no-op.

The asymmetry is what motivates dropping the default rather than keeping it: recovering from
"stuck in English" requires discovering that app_options exists, knowing it lives in
squirrel.custom.yaml and not default.custom.yaml, and writing patch syntax. Recovering from
"started in Chinese" is one keypress.

I deliberately kept this narrow. The sibling entries raise the same question to different degrees —
Atom was archived in 2022, Sublime Text 2 dates from 2011, TextWrangler was discontinued in 2017 —
but they are separate judgement calls and I did not want to bundle them into a change that can be
evaluated on its own. Happy to follow up on those, or to adjust the wording of the comment, if
maintainers would prefer a different shape.

Fixes #987

[JeremyLiu858]

Withdrawing this — on reflection the 2017 default looks deliberate rather than accidental, and this is better raised as discussion on #987 than as a unilateral change to a shipped default. Sorry for the noise.