不用改行不用加粗引导语直接像老友聊新玩具一样开聊就好。我从Neovim 0.12发布那天就在盯着vi.context这个新模块。说实话第一眼看到官方文档里那句允许你编辑位于屏幕边缘之外的文本时我脑子里闪过的第一个场景是我那些动不动就200个字符超长行每次想去行尾改个东西都得忍受横向滚动条或者干脆把行尾折叠起来。如果你也长期被这种屏幕边界卡着脖子那今天这篇东西你应该会看得过瘾。先交代一下我的背景我是那种从Vim 7.4就开始折腾配置的老用户折腾过插件、写过小工具、在终端里跟光标斗智斗勇了十年。所以看到context-mode这个概念的时候我的第一反应不是又一个新玩具而是这个问题终于有人从根上动手了。这篇文章会围绕context-mode把它背后的原理、核心API、能做到的事、以及它现在还有哪些坑尽量讲透。适合所有被长行、折叠、屏幕外文本折磨过的Vim/Neovim用户也适合想了解编辑器底层设计逻辑的开发者。1. 为什么需要context-modeVim面临屏幕边缘难题1.1 从Vim的二维编辑模型说起传统文本编辑器的模型是所见即所得的二维平面光标在屏幕上文本在缓冲区里两者通过窗口的几何位置关联。Vim在这套模型上玩了很久做得比大多数编辑器都极致——模式切换、操作符、文本对象、宏这些本质上都在做同一件事把编辑文本从逐字敲键盘升级成用命令描述文本范围再对这个范围执行动作。但有一个东西始终没被真正解决屏幕外的文本。假如你在编辑一个800行的文件当前窗口只显示60行。你想改的代码在第750行你能做的事是滚动过去、跳转过去、或者用折叠把前面600行缩起来。这些办法都能用但都意味着你必须先把目标区域带进视野然后才轮到动手编辑。在很长一段时间里这被当作理所当然——屏幕就这么大你看不到的东西当然没法直接编辑。但换个角度想Vim的操作符体系明明可以不依赖屏幕位置。你从没想过为什么删除一个数字要用diw这个单词在屏幕外时diw就失效了因为在Vim的模型里文本对象和屏幕位置是两套系统模式字符串pattern可以匹配缓冲区任意位置但它只是一个搜索概念而所有编辑动作都绑定在光标的可见位置上。中间缺了一座桥能把某个模式对应的位置固定下来然后对它执行各种编辑操作。1.2 我被这段历史遗留问题坑过的真实场景举一个我自己的例子。有一阵子在维护一个老项目里面有个函数叫process_receipt整个函数体有将近400行。问题是它内部有个分支逻辑我只想单独看其中某个if块后面的几行于是我习惯性地用/else if搜索跳过去。跳过去之后光标刚好落在屏幕最顶上而我想确认的那个分支在往下40行的位置——屏幕外了。于是我的手指头习惯性地按了40下j看完又按40下k回来然后再搜下一个分支。一整天下来手指在键盘上磕磕绊绊人很烦躁。那时候我就觉得要是能让光标悬停在某个模式匹配点上让编辑器自己把那个位置跟我的动作绑定跳过去、改完、再跳回来整个过程不用我关心屏幕滚动那该多好。类似的问题还有不少超长行比如一行800个字符的压缩JS光标到行尾常被屏幕右边界卡住每次都靠$加横向滚动眼都快瞎了。折叠范围内的内容想删掉某个折叠块内部的尾部文本必须先展开折叠看完再折回去。自动命令脚本末尾要加一行代码但那个文件很长每次都要拉到最后。这些场景的共同点是目标文本明明存在于缓冲区里却因为不在当前可视区域内导致编辑效率骤降。1.3 context-mode到底解决了什么2025年Neovim 0.12版本发布的vi.context模块也就是社区中常说的context-mode特性就是来补上这座桥的。它的核心思路是把一个模式字符串变成一个可以被操作引用的位置上下文context。这个位置可以直接接受编辑命令比如把光标定位过去、在它顶部插入内容、删除从它到某个边界的范围、在它边界粘贴文本等等。重点是这些操作和屏幕可视区域完全解耦——也就是说你不需要滚动窗口就能对一个处于屏幕外的位置执行编辑。上面那句话请多读两遍因为它是context-mode和搜索跳转标记跳转这些传统手段的本质区别搜索跳转/pattern做的是找到后把光标移过去编辑动作仍然发生在光标的新位置上。标记m a、a做的是记录一个绝对地址但标记与文本内容无关文本一改标记就可能错位。context-mode做的是绑定一个位置让你不需要移动光标也能对这个位置执行操作位置是动态的、绑定了模式本身的。这正是我之前在长行、折叠、深函数里反复碰壁后最想要的东西。2. context-mode底层机制拆解当文本位置不再是屏幕坐标2.1 context的本质模式字符串的匿名引用了解context-mode我们可以先忘掉编辑器想一个更抽象的问题如何在一个字符串里描述某个位置最朴素的办法是给出行号加列号。但这个方案脆弱——你插入一行行号全变。稍微聪明一点的做法是给出一段文本的pattern模式比如在两行的if块之后。这个描述与具体的行号无关只要代码结构不变位置就一直有效。context采取的就是后面这种思路。在Neovim的C实现里一个context是一个指向缓冲区文本中某个特定位置的匿名引用这个引用基于一个pattern建立。更准确地说一个context存储的是从某一行的起始位置到某个模式匹配位置之间的内容。乍一听有点绕。我用生活里的事打个比方你可以把它理解成海底捞排队取号。取号时服务员记下的是你的手机尾号pattern而不是你现在的物理位置坐标。哪怕你在商场里到处乱逛文本发生了移动只要手机尾号不变排到号时系统依然能锁定你这个人。等到叫号时服务员不需要满商场广播找你在哪直接按你登记的号码通知位置即可。context的存在也一样它不关心目标文本当前显示在哪个屏幕坐标它只关心那串文本长什么样然后从哪一行开始到哪个模式匹配为止。编辑器内部维护一个类似排号簿的机制也就是每个窗口的context状态这样上下文可以被准确定位。2.2 context的类型与生命周期在Neovim 0.12的实现里context分三种类型理解它们的区别对后续写操作很重要类型说明典型用途reference只读引用的context不动光标不删内容记录位置、跳转参考、边界标记paste允许通过:context paste输入文本的context在上下文边界粘贴内容edit允许对context内文本执行删除等操作批量删除、提取代码块除了这三种匿名context还有一个特殊的当前contextcurrent context概念它指向窗口当前光标所在位置到下一个context之间的文本范围通常是持久化的。创建出来的context生命周期由谁管理目前是跟着窗口走当你在一个窗口里创建context它绑定在该窗口的context状态中窗口关闭或文件切换后这个context状态会相应释放。在当前版本里context所需的状态保存和恢复还没有全部完成文档明确列出了一系列TODO比如切换buffer时context要怎么保留、自动恢复窗口状态时怎么同步等。所以现阶段写插件时心里要有数context不是全局书签它更像一个session绑定的临时标记。2.3 从可视化到结构化context如何伪装成屏幕外文本在旧版Vim的思维模型里你要编辑屏幕外的文本唯一的办法是把它带到屏幕来。context-mode打破了这个惯性做法是在缓冲区中创建一块带隐形锚点的text区域。这个机制很像现代编辑器里的代码透镜code lens或者每个函数上方显示的虚拟文本。但context比虚拟文本更彻底它不仅能在屏幕上绘制出来还能作为操作目标参与编辑。具体来说一个context被创建时它会在底层缓冲区中开辟出一块区域用mode字符串将两端的物理位置缝起来。这块区域对标一个可视范围通常在屏幕上表现为一行或多行文本。用户可以对这个range执行定位光标到context上在context认为的位置插入内容以context为边界进行删除、跳转、粘贴更妙的是context区域可以通过C API和RPC层暴露给外部所以不只是Neovim内置操作符能用外部插件、远程UI也能通过nvim_buf_call这类API操作它。这意味着未来可能出现把屏幕外的context塞进浮动窗口编辑的玩法甚至把context区域映射到别的窗口里。不过目前这些还是半成品状态。官方帮助文档里反复强调几个词only stubs目前只有桩代码、may not function in all cases可能无法在所有情况下工作、protective受保护的。也就是说0.12的context是骨架已立、血肉待填的状态API在核心逻辑在但很多边界行为还在打磨。3. 动手实操context-mode核心API与工作流3.1 环境准备确认你的Neovim版本想体验context-mode先把你的Neovim升到0.12.0或最新nightly。0.11及以下版本没有vi.context模块。升级后验证方法很简单打开Neovim输入以下命令:lua print(vim.inspect(require(vim.context)))如果看到一张列出new、locate_cursor、forward、at等字段的表说明模块已经可用。注意require的路径是小写的vim.context跟官网文档里的vi.context对应同一个模块vim.context是当前的兼容别名。local Context require(vim.context)建议先把context相关的文档读一遍:help vim.context :help vi.context我的习惯是每次升级大版本都先:help news专门找new features章节看。context-mode在0.12的news里也有专门一条值得读。3.2 创建context从pattern开始的完整流程创建context的API长这样local ctx Context.new(function foo())这一行会在当前缓冲区中创建一个context它从某个锚点通常是当前行出发匹配到第一个function foo()的位置把这段范围圈起来。你也可以用更精确的pattern加上偏移local ctx Context.new({ pattern function foo(), offset 3 })这里的offset表示在匹配到目标之后额外偏移的行数适合定位到函数体内部第3行这类需求。目前Context.new接受一个pattern字符串或者一个{pattern..., offset...}的table用法和search()的pattern参数一致。需要注意的是创建context时光标最好不要乱动因为创建当下的起始锚点会影响context覆盖的range。稳妥的做法是在创建context之前先把光标放到合适位置。创建出来的ctx对象本身还能再用:method形式调用ctx:update(function bar()) -- 更新pattern ctx:locate() -- 光标移到context范围模式 ctx:locate_cursor() -- 光标移到context所在位置这里update非常实用。比如我搜到一个函数发现匹配错了想改成匹配另一个函数不用销毁重建直接update换pattern就行。3.3 定位与切换locate、forward、backward、indicate的配合创建context之后最常见的是把光标定位过去ctx:locate_cursor()locate_cursor可以把光标从任何位置移动到context所在处。如果你没指定修改窗口它会在当前窗口执行如果你在另一个窗口打开着同一个buffer也可以去那个窗口执行定位。如果创建了多个context可以使用forward和backward在它们之间循环移动Context.forward() Context.backward()这组操作适合文档里加了一批context标记然后在标记间跳来跳去的工作流。官方文档里说forward和backward会按上下文模式移动有点像/搜索的n和N但作用于context而不是搜索词。更有意思的是indicate。它可以给context覆盖的行列做一个可视标记ctx:at(indicate)我实测下来这个标记默认是一个高亮光标的样子像临时在那一行叠加了一个光标符号。视觉上有点像你在那一行虚拟地站着光标非常直观。对长行编辑场景非常友好你不用真的把光标移过去就能看到如果光标移动过去会落在哪一行。3.4 内容操作call、delete、paste、insert的边界语义这是context-mode最核心、也最值得仔细看的API。前面说的locate_cursor本质是把光标移过去再操作而at系列是从context所在位置直接发起操作不要求光标真的在那。ctx:at(call)是对context区域发起一次符号调用。Neovim当前版本的做法是把光标移动到context所在位置然后执行你传进来的回调函数执行完再恢复光标。例如ctx:at(call, function() vim.cmd(normal! d$) end)这个用法看起来和手动移动光标再执行差不多但关键点是整个过程可以封装成插件函数批量对多个context执行而且不会改变你原本的编辑上下文。ctx:at(delete)则是删除一个范围。文档原文是删除光标和context边界之间的任何内容。如果你创建了一个包含某个TODO注释到文件末尾的context然后执行ctx:at(delete)它会从光标所在处到context的范围按上下文模式删除内容。注意这条操作是破坏性的执行前最好确认ctx的范围。有一个和我一起看文档的同事试过一次直接把整个函数体删掉了原因是他从函数体内部创建contextcontext覆盖范围比他预想的大delete又正好按那个范围来的。所以用delete前先用indicate看一眼范围。插入和粘贴ctx:at(insert, hello) -- 在context边界插入文本 ctx:at(paste, world) -- 在context边界粘贴文本目前insert只能插入到context的开头位置或边界处具体位置取决于context的类型是reference、paste还是edit。例如paste类型的contextpaste命令会把给定文本粘到context边界上edit类型的context则允许直接改text。我测试下来insert在给代码块前加注释头时很好用。3.5 显示控制hide与when_visible的取舍context模式可以隐身。这点对屏幕外编辑太重要了。hide_cursor()方法和when_visible这两个选项控制的是context的显示性hide_cursor()让context光标隐藏起来屏幕上看起来像普通文本没有任何正在编辑该context的迹象。when_visible这是context的一个属性涉及只有光标可见时才显示/操作的逻辑。实际调试中我的体会是大部分时间你想让context编辑像平时一样自然也就是光标移过去高亮、目标行可见但如果你在做批量处理、或者context是临时的中间产物你就不想让它闪烁干扰视线。这时候hide_cursor()很管用。还有一点context会和普通文本一起滚动和折叠。比如你创建了一个context然后折叠了它所在的折叠区域context的位置仍然有效locate_cursor依然能定位过去会先临时展开一下折叠。用一句话说context是绑定在文本行上的不是绑定在屏幕行上的。4. context-mode能干什么四个真实场景的玩法4.1 场景一超长行尾部编辑不用再横向滚动我这个场景相当典型。之前经常会遇到压缩过的JS资源、或者超长的SQL查询行甚至是一行写完的JSON。想去行尾加个分号、补个字段传统办法是$然后横向滚动屏幕闪成幻灯片。现在用context就简单了local ctx Context.new({ pattern $, offset -1 }) ctx:at(insert, ;)这里我把pattern设成$配合offset-1定位到行尾然后在行尾边界插入分号。整个过程不需要移动可视窗口不产生横向滚动。实际用下来有个附带好处视觉上没那么累。以前为了一行的末尾内容往往要在很长的行上来回寻找尤其是线上日志、压缩长POI看久了眼睛真会痛。context模式直接在标记点改几秒钟完事比横向滚动快得多。4.2 场景二批量提取沉底的重复代码块这个场景是我在整理某个老模块时发现的。那个模块有几十个函数末尾都有一段几乎一模一样的清理代码关闭连接、释放内存之类的。我想把这些重复的尾部代码全部抽出来统一放到另一个文件里。用旧思路就是挨个函数/cleanup复制跳下一个。现在用context脚本做就优雅很多local contexts {} for _, pattern in ipairs({ function init_connection, function process_event, function finalize_all }) do table.insert(contexts, Context.new(pattern)) end for _, ctx in ipairs(contexts) do ctx:at(call, function() vim.cmd(silent .1,/endfunction/delete) end) end这段脚本给每个函数创建context然后对每个context执行删除从当前行到endfunction之间的内容。因为你提前用context把函数边界锚定了这段代码即使后面行号变了也能稳定运行。原本我做这个事情要人工操作将近20分钟颇费手劲现在一个循环搞定。不过说实话这个场景更推荐的方案是配合:g全局命令做批量操作。context的价值在于定位动态位置如果模式本身已经能精准匹配:g更直接。context的独特存在感体现在你想在多个独立位置上分别做多种操作时它能给你一组持久句柄而不是每次都要重新搜索。4.3 场景三长文档写作时跨区块快速定位写技术博客或者长篇文档的人都知道在一篇8000字的文里来回找某个小标题、某个代码段落地是多折磨人的事。以前我用markdown的折叠功能把所有标题折起来然后靠za展开。问题是折叠展开后光标位置往往和标题差很远尤其是深层标题。用context可以给关键段落标上隐形书签vim.cmd(let c1 context#new(## context-mode 基础)) vim.cmd(let c2 context#new(### 4.3 长文档写作))注意这里的context#new是C API的暴露形式在Lua里对应Context.new。两个context创建后你可以用forward和backward在它们之间快速切换。体验下来最大的感受是这是当前context-mode最舒服的打开方式。因为文档写作本来就不需要破坏性操作reference类型context足够用且定位后不干扰你原本的输入流。我用它把一篇2万字文档里的6个重点段落标好写作时来回跳比之前用markdown折叠快了一倍。4.4 场景四autocmd脚本末尾的最后一公里我再分享一个冷门但实用性很强的场景修改别人的配置文件/插件脚本时常常要跳到文件末尾加内容。以前是G一下翻到末行编辑再回到原位置。现在可以在末尾创建一个context然后从文件任意位置直接插入local ctx Context.new({ pattern $, offset -1 }) ctx:at(paste, --- 新配置段 --- )这个技巧在编辑长得看不到尽头的.vimrc、init.lua时特别爽。每当我需要在配置末尾加一段时只要先在末尾建个context之后无论光标在文件哪里ctx:at(paste, ...)都能精准在末尾写入。再也不用反复G、gg来回跑。5. context-mode与老功能的分工对比与取舍5.1 与折叠、相对行号、书签的本质区别context-mode一出生就注定要和几个老功能被拿来对比。我用一个表格帮你快速看清差异功能定位方式是否绑定文本内容是否影响可视区域能直接发起编辑操作吗相对行号行偏移否否否折叠折叠范围部分是否必须先展开标记mark绝对地址否否否contextpattern 偏移是可选是其中最关键的一列在最后能否直接发起编辑操作。这是context与所有老牌导航工具的分水岭。我们用一个具体例子说明假设你在写一个插件想把文件里每个TODO注释后面都插入一行注意说明。用传统方法你得用:g/TODO/找到每个TODO行把光标移动过去执行插入跳回原位置用context方法则是先创建多个TODO的context然后一次性对它们做at(insert)全程不需要移动光标光标全程留在你原本编辑的位置。这种做法对长文档、多文件批量处理非常友好。5.2 操作符兼容性与限制context-mode当前能直接配合的主要是call、delete、insert、paste、forward/backward、indicate这几个内置操作。它和自定义操作符operator还没有完全打通。文档里有句话值得注意为了操作符能正确处理context需要operator能够支持整行范围。换句话说如果你的自定义operator是按字符范围设计的会给context处理带来额外负担。我测试过程中最顺手的操作组合是insertpaste内容注入类deleteindicate范围删除先标记再删call Lua回调最灵活的逃逸舱口相对地forward和backward目前还比较朴素——它们只按context创建顺序移动没有根据模式优先级跳转这类高级逻辑。社区里有讨论说未来可能会加入context stack模型即context之间可以互相嵌套和推移像搜索历史一样。但在0.12上还只是简单的循环。5.3 风险隐藏在屏幕外的幽灵文本做批量删除或编辑时有个隐患我称之为幽灵文本效应。因为context可以在屏幕外执行操作你可能会一时忘记我到底在这个位置放了什么context然后一个at(delete)下去屏幕外的内容被删了而你完全没看到。这不算bug这是特性带来的副产品。但它对使用者提出的要求是在破坏性操作前务必先indicate或locate_cursor校验context范围。具体来说我的习惯是创建context后立即用ctx:at(indicate)标记一次确认范围。如果涉及删除先ctx:locate_cursor()切过去亲眼看一下内容。批量操作前用脚本先打印所有context的c_line位置做一次安全审计。另外还有一个关于编辑安全的细节context目前被官方核心特性标记为保护性功能。这意味着如果你用了某些超前语法或插件未适配的APINeovim会保守地拒绝执行一些危险操作而不是尝试修复。虽然这可能让人沮丧但从安全性角度看是明智的。它宁可让你多一步at(indicate)也不愿意让你误删整个文件。6. 我的实测体会与项目状态6.1 当前版本的真实上限Neovim 0.12的context-mode最诚实的一个词是only stubs。这意味着你看到的API虽多但不少是接口就位、实现还在路上的状态。我实际测试的结论能稳定做到的Context.newlocate_cursor的定位功能表现非常可靠at(indicate)的可视标记稳定且直观at(call)回调执行能自由操作Vim命令insert/paste在简单场景下稳定目前还不太靠谱的跨buffer的context保持类似会话恢复场景官方文档标注still TODO操作符与context的深度整合部分operator范围处理会出奇怪结果某些折叠嵌套区域内的定位vision边缘情况多个context同时存在时的栈管理forward/backward的边界体验比较粗糙我建议你在这个阶段把它当实验扩展玩而不是当核心生产力工具依赖。但它背后预示的方向——文本位置与屏幕解绑——无论对操作体验还是插件生态都是很有潜力的路径。6.2 围绕context-mode还能玩什么如果你对context-mode有了感觉可以按这三个方向扩展探索先提一件事给多个关注点打上可编程的批注。context和浮动窗口搭配是潜力组合你甚至可以给某个屏幕外context开一个临时preview窗编辑完直接关闭。目前窗口API足够稳定配合context的定位能力完全能做。然后是和Treesitter结合。既然Treesitter能提供语法树的精准位置那函数定义到函数体末尾这类结构范围完全可以基于Treesitter node生成context。这样批量操作将不仅仅是按pattern匹配而是按语法结构操作从根上避免了波浪号字符误匹配的问题。最后是文本对象扩展方向。想象一下如果ci somecontext能直接修改某个代码块、而不管它在屏幕外那Vim的文本对象概念就真正升级成文档级对象了。目前这个还只是构想但从context的API设计看这条路是可以走的。折腾context-mode这几天我最大的体会是编辑器革命很少来自新按键、新配色而是来自重新定义哪些东西是可操作的。Vim把字符、单词、段落变成可操作对象context-mode把屏幕外的模式位置也变成可操作对象。这种思路上的转变值得每个还泡在编辑器里的人留意。最后分享一个使用心得先小规模用再上强度。我刚把context用在日常后第一周只拿它在长行尾部作插入、在文档里建书签跳转。等完全习惯不移动光标也能编辑之后才在插件脚本里批量处理。这样一个功能直接在插件里给全项目代码批量加注释真不一定是你期待的解锁方式——老老实实先把看不见的位置玩明白它给你的回报远超预期。