下面是一次 vim 的组内介绍的大纲。记录一下。
大纲
Vim 多模式编辑器
Normal mode
Insert mode
Visual mode
Command mode
插入模式
i 进入 insert mode,在光标为之前进入插入模式
I 行首非空字符前插入 , I 等同于 `^i`
s 删除光标下字符,并进入 insert mode, 等同于 `cl`
S 删除光标所在一行,并进入 insert mode 行首 , 等同于 `^C`
a 光标之后进入 insert mode
A 光标移动到行尾并进入 insert mode , 等
Read more ...
计算机中通常所说的寄存器 Register 一般指的是 CPU 中的寄存器,用来暂存 CPU 处理所需要的指令,数据等等。 Vim 中同样也有寄存器的概念,使用的方式和概念也和 CPU 是非常类似的。
Vim 的寄存器可以看成 Vim 中额外用来存储信息的区域,虽然看不见,但是如果使用 x, s, y, p 等等命令的时候都无意识的使用到了 Vim 的寄存器 (register).
Vim 中每一个 register 都可以通过添加双引号的方式来访问,比如 "a 来访问 a 寄存器。
可以通过选择然后使用 y 来将内容放到寄存器中,比如 "ay 来
Read more ...
Vim 的设计哲学中有这样一句话:”if you write a thing once, it is okay. However if you’re writing it twice or more times, then you should find a better way to do it”.
Vim 的 Macro 就是用来解决重复的问题。在 Vim 寄存器的文章里面已经对 macro 有所涉及, macro 的操作都是以文本的方式存放在寄存器中。
简单使用
录制 macro,在普通模式下使用 q + [a-z] 26 个字母中的一个:
Read more ...
Trellis:让 AI 编码代理真正投入生产的框架
最近我一直在思考一个问题:AI 编码工具越来越多,但为什么每次切换工具或开启新会话,都感觉像是从零开始?我用 [[Claude Code]] 写了一段时间,又想试试 [[Gemini]] CLI,但每次都要重新解释项目背景、编码规范、当前任务进度。这种重复性的”上下文喂养”工作,慢慢变成了一种隐性负担。
tiptop:用图表重新定义命令行系统监控
最近在排查一台服务器的性能问题时,我习惯性地打开了 [[htop]],盯着那一列列滚动的数字,试图从里面读出 CPU 负载的变化趋势。说实话,数字本身没什么问题,但当你需要判断”过去几分钟内 CPU 是否有明显的周期性抖动”时,一屏幕的百分比实在不如一条折线来得直观。就在那个时候,我发现了 tiptop 这个工具,用了之后感觉有点相见恨晚。
Claude Code /goal:让 AI 自主持续工作直到达成目标的新命令
用 [[Claude Code]] 写代码时,一直有一个令人微妙不适的摩擦:每当 Claude 完成一轮工作,控制权就回到了我这里,我需要再次发出指令,告诉它”继续”“再检查一遍”“还有这个文件没改”。对于那种需要跑很多轮才能完成的任务——比如把一个模块从旧 API 迁移到新 API 直到所有测试通过,或者逐文件重构某个目录直到符合统一规范——这个”人类中继”的环节就显得相当机械,本质上我只是在不停地按确认键。