Text Marker Plus：一个更适合日常使用的 VS Code 文本高亮插件

平时阅读代码、日志、配置文件或者一些比较长的文本时，我经常会遇到一个很简单但很实际的需求：

把当前比较关注的内容临时标出来。

例如分析一份比较长的日志时，我可能希望同时标记 ERROR、某个 Thread ID，以及几个关键函数名；阅读代码时，也可能希望给几个变量、状态或者调用路径分别加上不同颜色。

相比反复使用搜索框，这种持续存在的彩色高亮更容易帮助我建立视觉上的对应关系。

VS Code 本身当然提供了搜索和语法高亮，但如果想自由地给任意文本增加多组高亮，并且让这些高亮在重新打开项目后仍然保留，体验并没有那么直接。

因此最近我把自己维护的一版文本高亮插件整理了一下，并正式发布到了 Visual Studio Marketplace：

Text Marker Plus

Marketplace：

Text Marker Plus — Visual Studio Marketplace

Extension ID：

Williamslay.text-marker-Plus

Text Marker Plus 基于开源项目 ryu1kn/vscode-text-marker 继续维护。

它并不是对原项目进行完全重写，而是在保留原有使用方式的基础上，针对我自己在日常使用中遇到的一些问题进行了补充和改进，包括：

  • 更方便的高亮保存机制
  • Workspace / Global 两种保存范围
  • Toggle 后自动保存
  • 多个可见编辑器同步刷新
  • 大文件匹配时的异步处理
  • 匹配结果缓存
  • 更丰富的默认配色
  • 用户自定义颜色扩展

为什么需要一个 Text Marker？

VS Code 已经有搜索：

Ctrl + F
Ctrl + Shift + F

也有完善的语法高亮。

但它们和 Text Marker 解决的问题其实不太一样。

搜索更偏向：

“帮我找到这个东西在哪里。”

而 Text Marker 更偏向：

“接下来的一段时间里，我希望这些东西一直显眼。”

比如阅读一个复杂函数时，我可能想分别高亮：

buffer_
async_read_in_progress_
ReadAsync
Prefetch

然后在接下来的代码阅读过程中不断观察它们之间的关系。

这时候我并不希望不停地：

Ctrl + F
→ 输入关键字
→ 看搜索结果
→ 再换另一个关键字

而是希望这些关注点能够同时存在于编辑器里。

这也是 Text Marker 这类工具比较有价值的地方。

基本使用

最常见的用法很简单。

选中一段文本，然后执行：

Toggle Highlight

插件会将对应文本高亮显示。

除了普通文本匹配之外，也可以根据具体规则使用：

  • 普通字符串匹配
  • 正则表达式
  • 大小写敏感 / 不敏感
  • 整词匹配 / 部分匹配

同时也可以在不同的匹配结果之间进行跳转。

因此它既可以用于：

ERROR
WARNING

这样的日志关键字，也可以用于：

async_read_in_progress_

这样的代码变量，还可以通过正则表达式标记更加复杂的文本模式。

高亮可以保存下来

这是我比较在意的一项功能。

如果高亮只能存在于当前 VS Code Session，那么关闭编辑器之后，之前花时间建立的一组视觉标记就全部消失了。对于临时搜索来说这没有问题。但如果正在阅读一个持续数天的代码模块，这种行为就会比较麻烦。

Text Marker Plus 支持将当前高亮规则保存下来，并增加了默认保存目标的配置：

{
  "textmarker.defaultSaveTarget": "workspace"
}

目前可以选择：

workspace
global
prompt

它们分别适合不同场景。

Workspace

{
  "textmarker.defaultSaveTarget": "workspace"
}

高亮规则只属于当前 Workspace。

这也是我自己最常使用的模式。

例如：

RocksDB project
    ├── buffer_
    ├── ReadAsync
    └── async_read_in_progress_

另一个 project
    ├── request
    ├── token
    └── cache

两个项目可以维护完全不同的关注点。

重新打开 Workspace 后，对应的高亮规则仍然可以恢复。

Global

如果某些规则希望在所有项目中使用，则可以保存为全局规则。

例如：

TODO
FIXME
ERROR
WARNING

这类规则可能并不属于某个特定 Workspace。

Prompt

如果不希望固定默认行为，也可以设置为：

{
  "textmarker.defaultSaveTarget": "prompt"
}

这样保存时再决定放到 Workspace 还是 Global。

Toggle 后自动保存

另一个我自己比较喜欢的配置是：

{
  "textmarker.autoSaveOnToggle": true
}

开启以后，每次通过 Toggle Highlight 添加或者删除高亮规则时，插件都会自动保存当前状态。

这时候整个使用体验就比较接近：

选中文本
    ↓
Toggle Highlight
    ↓
自动保存到当前 Workspace
    ↓
关闭 VS Code
    ↓
重新打开
    ↓
高亮仍然存在

这样高亮实际上就变成了项目阅读状态的一部分。

多个编辑器同步刷新

这是一个看起来很小，但实际使用中比较容易注意到的问题。

我平时经常使用 Split Editor，例如：

┌─────────────────────┬─────────────────────┐
│ block_prefetcher.cc │ block_prefetcher.h  │
│                     │                     │
│                     │                     │
├─────────────────────┼─────────────────────┤
│ benchmark log       │ experiment config   │
│                     │                     │
└─────────────────────┴─────────────────────┘

假设我此时增加了一个高亮：

async_read_in_progress_

理想行为显然是：

所有当前可见的 Editor 都立即更新。

而不是只有当前获得焦点的那个 Editor 更新。

Text Marker Plus 对这一部分进行了调整。

现在修改高亮规则以后，会刷新所有当前可见的编辑器区域，包括没有 Focus 的 Split Pane。

对于已经打开但目前不可见的 Tab，则会在它重新变成可见状态时更新。

对于经常同时查看：

.cc + .h

或者：

源码 + 日志

这种场景，这个行为会自然很多。

大文件匹配与 Extension Host

文本高亮还有一个比较容易被忽略的问题：

匹配本身也是计算。

假设当前打开的是一个非常大的日志文件，并且配置了很多高亮规则。

如果插件每次更新都直接在 VS Code Extension Host 中执行整份文档扫描，那么可能出现：

修改高亮规则
        ↓
扫描整个 Document
        ↓
大量 Regex / String Matching
        ↓
Extension Host 被占用
        ↓
VS Code 操作出现延迟

问题并不是 Text Marker 本身逻辑有多复杂，而是这种工作不应该长时间阻塞 Extension Host。

因此 Text Marker Plus 目前将 full-document matching 放到了独立 Worker 中处理。

整体思路类似：

VS Code Extension Host
        │
        │ matching request
        ▼
Worker
        │
        │ scan document
        │ regex/string match
        ▼
matching result
        │
        ▼
Extension Host
        │
        ▼
Apply Decorations

这样可以减少大文件匹配直接阻塞 Extension Host 的情况。

匹配结果缓存

除了把匹配过程移出主要执行路径之外，插件还会对已经完成的匹配结果进行缓存。

缓存会考虑类似：

Document
Document Version
Highlight Rule

这样的信息。

如果：

文档没有发生变化
+
高亮规则没有发生变化

那么没有必要重新做完全相同的全文扫描。

同时，因为匹配是异步执行的，还存在另一个问题：

开始扫描 version 10
        ↓
用户继续编辑
        ↓
Document 已经变成 version 11
        ↓
version 10 的匹配结果才返回

这种情况下，旧结果已经失效。

因此当异步结果返回时，如果发现 Document Version 已经发生变化，旧结果会被丢弃，而不是重新应用到编辑器。

这部分也是我比较关注的一个方向：

文本高亮应该是一种辅助功能，它不应该反过来成为编辑器卡顿的来源。

默认配色

Text Marker Plus 对默认配色也做了一些调整。

当前配色主要沿着 One Half Dark 的 Accent Color 风格扩展。

我希望这些颜色在 Dark Theme 下：

  • 有足够明显的区分度
  • 不至于特别刺眼
  • 多组颜色同时出现时仍然比较协调

相比于非常高饱和度的 Marker Color，我更倾向于让它保持接近编辑器本身的配色语言。
在这里插入图片描述

自定义颜色

当然，默认颜色不可能满足所有 Theme。

因此也可以通过配置增加自己的颜色，例如：

{
  "textmarker.useUserColor": true,
  "textmarker.userColor": [
    "#E06C75",
    "#E5C07B",
    "#98C379",
    "#56B6C2",
    "#61AFEF",
    "#C678DD"
  ]
}

用户颜色会加入可以使用的颜色序列。

因此如果自己的 VS Code Theme 有一套固定 Palette，也可以让 Text Marker 尽可能保持一致。

例如：

One Half Dark
Nord
Dracula
Tokyo Night
Catppuccin

都可以自己配置更适合的 Marker Color。

安装

目前 Text Marker Plus 1.0 已经发布到 Visual Studio Marketplace。

可以直接在 VS Code Extensions 中搜索：
在这里插入图片描述

Marketplace：

https://marketplace.visualstudio.com/items?itemName=Williamslay.text-marker-Plus

关于项目

Text Marker Plus 基于原有的 vscode-text-marker 项目继续维护。

当前版本仍然保持比较克制的方向：不重新设计整个工作流，而是在原有 Text Marker 使用方式上解决一些我自己确实遇到的问题。包括：

Persistence
Workspace scope
Auto Save
Multi-editor refresh
Async matching
Caching
Color palette

项目继续采用 MIT License，并保留原项目对应的版权与许可证信息。

如果在使用过程中发现 Bug，或者有一些比较自然的改进想法，也欢迎反馈。

posted @ 2026-10-03 16:59  WilliamsLay  阅读(3)  评论(0)    收藏  举报