端末のセットアップ

Pi は、信頼性の高い修飾キー検出のために Kitty keyboard protocol を使用します。最新の端末のほとんどはこのプロトコルをサポートしていますが、一部の端末では設定が必要です。

箱から出してすぐに使えます。

Pi により、利用可能な場合は拡張キー レポートが有効になります。 Terminal.app が引き続き Shift+Enter に対してプレーンな Return を送信する場合、pi はローカル macOS 修飾子のフォールバックを使用して、その Return を Shift+Enter として扱います。

このフォールバックは、pi が Terminal.app と同じ Mac 上で実行されている場合にのみ機能します。リモート SSH 経由でローカル キーボードを検出できません。

Ghostty 構成に追加します (macOS では ~/Library/Application Support/com.mitchellh.ghostty/config、Linux では ~/.config/ghostty/config):

keybind = alt+backspace=text:\x1b\x7f

古いクロード コードのバージョンでは、次の Ghostty マッピングが追加されている可能性があります。

keybind = shift+enter=text:\n

そのマッピングは生の改行バイトを送信します。 pi の内部では、これは Ctrl+J と区別できないため、tmux と pi には実際の shift+enter キー イベントが表示されなくなります。

クロード コード 2.x 以降がそのマッピングを追加した唯一の理由である場合は、その Ghostty マッピングが依然として必要な tmux でクロード コードを使用する場合を除き、それを削除できます。

Pi は、デフォルトの改行エイリアスとして Ctrl+J をバインドするため、追加の pi 設定を行わずに、その再マップを介して Shift+Enter が tmux で動作し続けます。

WezTerm は通常、xtermmodifyOtherKeys を介して Shift+Enter に対してそのまま使用できます。 Kitty キーボード プロトコルを明示的に使用するには、~/.wezterm.lua を作成します。

local wezterm = require 'wezterm'
local config = wezterm.config_builder()
config.enable_kitty_keyboard = true
return config

macOS では、WezTerm はデフォルトで Option+Enter を全画面にバインドします。 pi フォローアップ キューイングに Option+Enter を使用するには、次のキー オーバーライドを追加します。

local wezterm = require 'wezterm'
local config = wezterm.config_builder()
config.keys = {
  {
    key = 'Enter',
    mods = 'ALT',
    action = wezterm.action.SendString('\x1b[13;3u'),
  },
}
return config

すでに config.keys テーブルがある場合は、そこにエントリを追加します。

WSL では、WezTerm は IME 候補ウィンドウの位置決めに可視ハードウェア カーソルを必要とする場合があります。 CJK IME 候補がテキスト カーソルに追従しない場合は、pi を実行する前に PI_HARDWARE_CURSOR=1 を設定するか、設定で showHardwareCursor を true に設定してください。

Alacritty は通常、何も設定しなくても Shift+Enter で機能します。 macOS では、Option+Enter がプレーンな Enter として到着する場合があります。 PI フォローアップ キューイングに Option+Enter を使用するには、~/.config/alacritty/alacritty.toml に追加します。

[[keyboard.bindings]]
key = "Enter"
mods = "Alt"
chars = "\u001b[13;3u"

設定を変更した後、Alacritty を再起動します。

VS Code 1.109.5 以降では、統合ターミナルで Kitty キーボード プロトコルがデフォルトで有効になっているため、Shift+Enter はそのまま使用できるはずです。

1.109.5 より古い VS Code バージョンでは、Shift+Enter に対する明示的なターミナル キーバインドが必要です。

keybindings.json 場所:

• macOS: ~/Library/Application Support/Code/User/keybindings.json
• Linux: ~/.config/Code/User/keybindings.json
• Windows: %APPDATA%\\Code\\User\\keybindings.json

keybindings.json に追加:

{
  "key": "shift+enter",
  "command": "workbench.action.terminal.sendSequence",
  "args": { "text": "\u001b[13;2u" },
  "when": "terminalFocus"
}

pi が使用する変更された Enter キーを転送するには、settings.json (Ctrl+Shift+、または [設定] → [JSON ファイルを開く]) に追加します。

{
  "actions": [
    {
      "command": { "action": "sendInput", "input": "\u001b[13;2u" },
      "keys": "shift+enter"
    },
    {
      "command": { "action": "sendInput", "input": "\u001b[13;3u" },
      "keys": "alt+enter"
    }
  ]
}

• Shift+Enter は新しい行を挿入します。
• Windows ターミナルは、デフォルトで Alt+Enter を全画面にバインドします。これにより、pi はフォローアップ キューイング用の Alt+Enter を受信できなくなります。
• Alt+Enter を sendInput に再マッピングすると、代わりに実際のキーコードが pi に転送されます。

すでに actions 配列がある場合は、そこにオブジェクトを追加します。以前の全画面表示の動作が続く場合は、Windows ターミナルを完全に閉じてから再度開きます。

これらの端末では、エスケープ シーケンスのサポートが制限されています。 Ctrl+Enter や Shift+Enter などの変更された Enter キーは、通常の Enter と区別できず、submit: ["ctrl+enter"] などのカスタム キーバインドが機能しなくなります。

最適なエクスペリエンスを得るには、Kitty キーボード プロトコルをサポートする端末を使用してください。

• Kitty
• Ghostty
• WezTerm
• iTerm2
• Alacritty (Kitty プロトコルをサポートするコンパイルが必要)

組み込みターミナルでは、エスケープ シーケンスのサポートが制限されています。 IntelliJ のターミナルでは、Shift+Enter と Enter を区別できません。

ハードウェア カーソルを表示したい場合は、pi を実行する前に PI_HARDWARE_CURSOR=1 を設定します (互換性のためにデフォルトでは無効になっています)。

最高のエクスペリエンスを得るには、専用のターミナル エミュレーターの使用を検討してください。