## 事象
1. [[Obsidian]]で[[Live Preview]]有効時にテーブルにカーソルをあわせる
2. `g,j` のようにテーブル編集コマンドを[[Vimrc Support Plugin (Obsidian)|Vimrc Support Plugin]]経由で実行
-> 既に起動中の[[Ghostty]]のウィンドウが消える
- 再びそのウィンドウを表示できない
- プロセスはずっと残っている
`obsidian.vimrc` の設定における関係しそうな箇所は以下。
```
" テーブル操作
noremap g,j :obcommand<Space>editor:table-row-after<CR>
noremap g,k :obcommand<Space>editor:table-row-before<CR>
noremap g,l :obcommand<Space>editor:table-col-after<CR>
noremap g,h :obcommand<Space>editor:table-col-before<CR>
noremap g,d :obcommand<Space>editor:table-row-delete<CR>
noremap g,yj :obcommand<Space>carnelian:carnelian_duplicate-line-down<CR>
noremap g,yk :obcommand<Space>carnelian:carnelian_duplicate-line-up<CR>
```
### 環境
| 対象 | バージョン |
| ------------ | ------ |
| [[macOS]] | 26.5 |
| [[Ghostty]] | 1.3.1 |
| [[Obsidian]] | 1.12.7 |
## 原因
調査中...
試しに[[設定ファイル (Ghostty)|設定ファイル]]に以下を追加してみて様子見。
```
# Note: ObsidianでGhosttyを削除してしまう誤動作の対策に効くかもしれないので実験
keybind = super+shift+w=unbind
```
## 解決方法
> [!fixme]
>
## 調査
> [!left-bubble] ![[chappy-mini.webp]]
> [[Codex CLI]]の調査結果です。
調査のみで、ファイル変更はしていません。
**結論**
最有力は `g,j` そのものではなく、別経路で Ghostty の「ウィンドウが閉じる/隠れる」操作が入っている可能性です。特に `super+shift+w=close_window` が Ghostty に残っている点が怪しいです。
確認した事実:
- mnt/obsidian/obsidian.vimrc の `g,j` は `editor:table-row-after` だけです。Ghostty に触る処理ではありません。
- mnt/ghostty/config で `super+w` は `esc:w` に上書きされています。通常の Cmd+W では Ghostty の surface close になりません。
- ただし `ghostty +list-keybinds --plain` では `super+shift+w=close_window` が有効なままでした。これは Ghostty 公式 docs 上も「現在のウィンドウを閉じる」アクションです。
- Ghostty の macOS デフォルトは `quit-after-last-window-closed = false` です。つまり最後のウィンドウを閉じてもプロセスだけ残る挙動は自然です。公式 docs でも macOS では標準挙動として `false` と説明されています。
- Ghostty には `toggle_visibility` という「全ウィンドウを表示/非表示」アクションがあり、過去 issue でも「Dock アイコンをクリックしても戻らない」系の macOS 問題が報告されています: `#3219` `#8414`
**可能性の順位**
1. **Cmd+Shift+W 相当が誤入力/誤変換されて Ghostty の `close_window` が発火**
- Ghostty の実設定に `super+shift+w=close_window` が残っています。
- 「ウィンドウが消えるがプロセスは残る」という症状と一致します。
- Obsidian 側にも `workspace:close-others = Mod+Shift+W` があり、Karabiner の modifier 入れ替えや sticky 状態が絡むと紛らわしいです。
2. **Ghostty の `toggle_visibility` 系、または外部ウィンドウ管理ツール経由で hide 状態になっている**
- このリポジトリ内の Ghostty config には `toggle_visibility` keybind はありません。
- ただし `; Space` で JINRAI window hints、`半全` 系で window mover、`SPECIAL` mode でウィンドウ移動/リサイズ系があり、外部ツール側の設定までは今回の範囲外です。
- Ghostty 側には実際に macOS hide/visibility 周りの既知 issue があり、症状の近さはあります。
3. **Karabiner の sticky modal layer が残って、想定外のキー列になっている**
- karabiner/modes/normal.ts では Normal mode 中の `g` が Range mode に遷移します。
- ただし `g,j` から直接 Ghostty close/hide に到達する定義は見つかりませんでした。
- 「たまに」発生するなら、発生直前に Karabiner mode indicator が NORMAL/RANGE/SPECIAL になっていないかを見る価値があります。
**切り分け案**
- Ghostty 側で一時的に `keybind = super+shift+w=unbind` を入れて再現性を見る。
- 発生直後に `ghostty +new-window` または Ghostty メニューの New Window で復帰できるか確認する。復帰できるなら close_window 系、復帰できない/再表示だけ必要なら visibility/hide 系が濃いです。
- Karabiner EventViewer で発生直前の実入力が `left_gui+left_shift+w`、`cmd+h`、`toggle_visibility` 用のグローバルキーに化けていないか確認する。
- Ghostty の公式 docs 上、`undo` は close window/tab/split を短時間だけ復元できます。発生直後に Cmd+Z または Cmd+Shift+T で戻るなら、close_window/close_surface 系でほぼ確定です。