iron.nvim：把 REPL 拉進 Neovim 緩衝區，但你要先想清楚視窗策略

它解決的問題：在編輯與執行之間切換的摩擦

iron.nvim 想解決的，是開發者在編輯程式碼與執行 REPL 之間反覆切換視窗的麻煩。傳統做法是開一個終端機，手動輸入指令，或者用 tmux 分割畫面，但這些都要求你離開目前的緩衝區。iron.nvim 的做法是，讓 REPL 變成 Neovim 內部的一個視窗，你可以直接從工作緩衝區傳送程式碼過去。文件說，它「允許你快速與 REPL 互動，而不必離開你的工作緩衝區」。這對 Python、Haskell 或 shell 這類有互動直譯器的語言特別有用。它同時是外掛也是函式庫，意思是你不只可以用它現成的功能，還可以把它當作底層 API 來建自己的工具。但這也暗示，它的目標使用者不是初學者，而是願意寫 Lua 設定的人。

核心機制：repl_definition 與 command 的彈性

iron.nvim 的設定核心是 repl_definition 這個表格，裡面定義了每個檔案類型要啟動什麼 REPL。最簡單的寫法是指定一個命令陣列，例如 python 的 command = { "python3" }。但更進階的用法是，command 可以是一個函式，這個函式接收 meta 參數，裡面包含 current_bufnr，你可以用它來動態產生命令。README 給了一個 Haskell 的範例，用 cabal v2-repl 載入目前檔案。這個設計的彈性很大，因為你可以在函式裡讀取緩衝區名稱、環境變數，甚至根據專案類型切換直譯器。但反過來說，這也代表你必須自己寫這些邏輯，外掛沒有提供任何預設的智慧判斷。文件的範例很簡短，沒有說明 meta 結構還有哪些欄位，這是一個需要自己探索的點。

視窗管理：split 與 float 的兩套 API

iron.nvim 提供兩種 REPL 視窗模式：分割視窗（split）與浮動視窗（float）。分割視窗的設定是透過 repl_open_cmd，你可以直接寫 Vim 命令，例如 "vertical botright 80 split"。但外掛也提供 view 模組，裡面有輔助函式，可以用更程式化的方式宣告視窗位置。文件提到 split 有 metatable，支援 fluent API，可以寫「vertical」「leftabove」這類關鍵字。浮動視窗則有 view.top、view.center 等函式，可以指定百分比或絕對尺寸。view.center 接受一個或兩個參數，如果只給一個，寬高都會用同一個值。它還接受一個函式，這個函式會被呼叫兩次，一次算寬度一次算高度，你可以根據方向回傳不同數字。這套 API 的設計很靈活，但文件在 split 的範例中斷了，只寫到「They'l」，後面就沒了。這代表你必須自己去閱讀原始碼才能知道完整的參數列表。對一個號稱「使用者體驗好」的外掛來說，文件這樣斷尾是明顯的缺點。

實際安裝與最小設定：從 README 拼出可用的東西

安裝很簡單，用 packer.nvim 寫 use {'Vigemus/iron.nvim'} 就可以。設定則需要呼叫 iron.setup，並傳入 config 表格。最簡單的設定只包含 scratch_repl 和 repl_definition。scratch_repl 決定 REPL 是否應該被丟棄，文件沒有詳細解釋這個選項的後果，但從字面上推測，它可能與緩衝區的生命週期有關。repl_definition 裡面，sh 和 python 的範例都很直接。python 的範例還包含 format = common.bracketed_paste_python，這表示 iron.nvim 支援 bracketed paste 協定，讓貼上多行程式碼時不會觸發縮排問題。另外 block_dividers = { "# %%", "#%%" } 看起來是用來偵測程式碼區塊的分隔線，可能是為了傳送整個 cell。但文件沒有說明這些設定如何與按鍵綁定互動，也沒有提到任何預設的快捷鍵。這意味著你必須自己定義 keymap，呼叫 iron.core 的函式來傳送程式碼。對一個外掛來說，缺少預設按鍵是很大的門檻。

文件不足與潛在的失敗模式

iron.nvim 最大的問題是文件不完整。README 的範例在 split 的段落中途截斷，留下「They'l」這種未完成的句子。view 模組的函式沒有完整的參數說明，repl_definition 的 meta 結構也只有 partial 描述。這對一個強調「可擴展性」的函式庫來說是致命的，因為你無法在不閱讀原始碼的情況下寫出進階設定。另一個失敗模式是 bracketed paste 依賴。如果你的 REPL 不支援 bracketed paste，例如某些老舊的 shell 或客製化的直譯器，那麼 python 的 format 範例可能會導致貼上內容時出現額外的控制字元。文件沒有提到如何偵測或處理這種情況。此外，scratch_repl 的語義不清楚，如果設定錯誤，可能導致 REPL 緩衝區被意外關閉或保留。這些都是你在採用前需要自己驗證的。

替代方案：與 Neovim 內建終端機的比較

最直接的替代方案是 Neovim 內建的 :terminal 命令，搭配 :term 開啟一個終端機緩衝區。你可以用 :normal 或 :call 來傳送文字到終端機，但這需要自己寫很多膠水程式碼。iron.nvim 的優勢在於它把 REPL 的啟動、視窗管理和傳送邏輯封裝成一個 API，你不需要自己處理緩衝區的切換。但內建終端機的優勢是零依賴，而且 Neovim 官方持續維護，不會有文件斷尾的問題。另一個替代方案是使用 tmux 搭配外掛如 vim-tmux-navigator，但這需要你在 Neovim 外管理 tmux 的 pane，而且不是純 Neovim 的體驗。iron.nvim 的取捨是：它提供了更整合的體驗，但代價是你必須信任一個文件不全的專案。如果你不介意閱讀原始碼，iron.nvim 的函式庫設計可能比內建終端機更優雅。

維護成本與授權考量

iron.nvim 使用 BSD-3-Clause 授權，這允許你自由使用、修改和重新發布，只要保留版權聲明。這對商業使用是友善的。但從維護角度來看，這個專案沒有列出最近的發布版本，最後的 push 時間也不明。README 提到 asciinema 的連結，但沒有更新日期。這表示你可能需要自行追蹤 master 分支的變動，因為沒有穩定的 release 標籤。如果你要把它整合進大型專案，建議鎖定 commit hash，而不是追蹤 master。另外，由於它是 Lua 寫的，升級時需要確認你的 Neovim 版本相容，但文件沒有指定最低版本。總體來說，授權是寬鬆的，但維護的不確定性是一個需要考慮的風險。

編輯結論

iron.nvim 適合那些已經熟悉 Neovim 設定，且願意用 Lua 撰寫自訂 REPL 命令的開發者。如果你只是想要一個開箱即用的 REPL 按鍵綁定，這不是你的工具，因為文件沒有提供任何預設按鍵，你需要自己從 README 的片段拼出完整設定。不適合的人包括：不喜歡閱讀原始碼來補齊文件缺口的人，或者依賴圖形介面管理視窗的人。在採用前，你應該先確認你的直譯器是否支援 bracketed paste，因為 python 的 format 範例依賴這個協定，如果你的 REPL 不支援，貼上多行程式碼時可能出現縮排錯誤。另外，確認你的 Neovim 版本至少支援 Lua 的 require 機制，因為整個外掛都是建立在這個基礎上。最終判斷：iron.nvim 的價值在於其 repl_definition 的函式化設計，但文件不完整會讓初次設定花費大量時間。

官方來源

1. Official README
2. Project repository