Atom不支持设置撤销/重做步数上限，因其撤销栈由TextBuffer底层管理且无editor.undoStackSize等配置项；唯一可调参数是core.undoGroupingInterval（控制操作合并粒度），无法限制历史步数。
Atom 不支持设置撤销/重做步数上限——它没有类似 editor.undoStackSize 这样的配置项，所有撤销历史都由底层 TextBuffer 管理，且不对外暴露可调参数。
为什么 config.cson 里找不到 undo 步数配置
Atom 的撤销栈（undo stack）是基于操作快照（snapshot）实现的，每个 insert、delete、replace 操作都会生成一个独立快照。这些快照默认无限缓存于内存中，直到：
- 编辑器重启（全部清空）
- 文档被关闭且未保存（部分快照释放）
- 内存压力触发 GC（不可控、无日志）
它不像 VS Code 或 Sublime 那样提供 editor.undoCount 类配置，也不读取 core.undoGroupingInterval 以外的任何相关 setting。
唯一能间接影响撤销行为的配置
虽然不能设“步数上限”，但以下两项会影响撤销粒度和感知长度：
- core.undoGroupingInterval：默认 200ms，控制多步小操作是否合并为一次撤销单位。值越小，Ctrl+Z 越“细碎”（比如连打 5 个字母可能被拆成 5 步）；值越大，越容易合并（如快速删一行 + 补内容 → 1 步撤销）。可在 config.cson 中修改：
core: undoGroupingInterval: 500-
core.restorePreviousTabPositions：仅影响重启后光标位置，与撤销栈无关，但常被误认为“历史保留机制”
常见误操作与实际效果
用户常尝试以下方式，但均无效：
- 在 config.cson 中添加 editor.undoSteps: 100 或 core.maxUndoHistory: 50 → Atom 启动时忽略该字段，无报错也无作用
- 使用 apm install atom-undo-manager 类插件 → 社区无成熟维护插件，已有项目（如 undo-redo-manager）在 Atom 1.26+ 上已失效或导致崩溃
- 修改 TextBuffer.prototype 原型链 → 主线程不可靠，重启即丢，且违反 Atom 安全模型
真正需要限制撤销深度的场景（如教学环境防误操作），只能靠外部手段：定期关闭并重开文件，或改用支持该配置的编辑器。Atom 的设计哲学是“撤销即可靠”，而非“撤销可裁剪”。
