13k star，微软用rust 开发的 文本编辑器 Edit：轻量级终端编辑的务实之选。 是一款轻量级、开源的命令列文字编辑器，它向经典的MS-DOS 编辑器致敬，但拥有类似VS Code 的现代介面与输入控制。Windows 11及之后，微软准备系统自带它，可见它确实很实用。

更多交流学习，欢迎加入开源鸿蒙PC社区：https://harmonypc.csdn.net/

背景

edit 是微软开源的一款现代化终端文本编辑器，使用 Rust 编写，采用类 Kakoune/Helix 的编辑模型。它原生支持 Linux、macOS 和 Windows，其中 Unix 平台通过 crates/edit/src/sys/unix.rs 对 libc 做系统调用。

Linux 发行版和苹果 macOS 系统通常自带 Vim 和 Nano 编辑器，反观 64 位 Windows 系统，一直缺少一款原生的命令行文本编辑器。这个奇怪的疏漏迫使开发者和系统管理员长期依赖第三方工具，或使用功能日益臃肿的记事本（Notepad）进行快速编辑。

微软工程团队也承认这一历史空白，因此推出了 Edit 编辑器，旨在为用户提供一个现代化、轻量级的官方解决方案。Edit 的出现不是为了"加冕"或"废黜"任何编辑器，而是丰富终端工具箱的务实之举。Vim 依然统治重度文本操作场景，VS Code 主导 GUI IDE 领域，而 Edit 则优雅地接管了"快速修个配置"这类轻量任务。

作为一个开源项目，Edit 体积不足 1MB，却具备了多项现代化特性。用户不仅可以使用键盘快捷键，还能直接通过鼠标进行交互操作。此外，它支持多文件编辑（Ctrl + P 切换），并提供了带“大小写匹配”、“全词匹配”和“正则表达式”选项的查找与替换功能。

随着 Edit 的开源，尤其是其跨平台特性，令不少用户感到惊喜。

有 Reddit 用户感慨：“等了 30 年，我终于能在 Linux 上用 MS Edit 了！”

独立 AI 研究员 Simon Willison 也在 X（前 Twitter）上分享了自己的试用体验：“微软发布了一个全新的终端文本编辑器！它叫 Microsoft Edit，是开源的，Rust 编写，编译后体积只有 250KB，并且支持跨平台。我在 Mac 上试了一下，是个不错的 Vim 或 nano 替代品。”

鸿蒙 PC（OpenHarmony） 的 Rust 目标三元组为 aarch64-unknown-linux-ohos，其 target_os = "linux"、target_env = "ohos"、target_family = "unix"。这意味着大部分 Unix 代码天然可用，但仍需处理一些 libc 层的小差异。

github地址：https://github.com/microsoft/edit

在Windows上体验：

#powershell中执行以下命令安装
winget install Microsoft.Edit
#或者从github上下载：
wget https://github.com/microsoft/edit/releases/download/v2.0.0/edit-2.0.0-x86_64-windows.zip

官方介绍地址：https://learn.microsoft.com/zh-tw/windows/edit/

使用很简单，在命令行窗口，要开启编辑，edit输入命令列，或执行edit 以开启特定档案。 你可以直接在终端机编辑档案，不用切换上下文。

特色

编辑具有多种预设功能。

• 无模式编辑：Edit 采用无模式介面搭配文字使用者介面（TUI），因此无需学习模式。 所有选单选项也都有预设的按键绑定。

• 多个档案：用Ctrl+P开启并切换多个档案。

• 查找与替换：用Ctrl+F搜寻并替换文字，或在TUI 选单中选择编辑> 寻找。 支援Match Case、Whole Word 和Regular Expression 选项。

• 自动换行：使用Alt+Z切换自动换行，或在TUI 选单中选择[检视] > [自动换行]。

• 滑鼠支援：使用滑鼠来浏览选单、选择文字并卷动。

类似的还有这个fresh editer工具 ：https://github.com/sinelaw/fresh，体验也不错。

如何在鸿蒙PC上使用？

在鸿蒙PC本机上，Harmonybrew包管理工具，已经有了这个命令行工具。直接安装即可（需先安装包管理工具Harmonybrew）。

brew install msedit

强烈推荐Harmonybrew包管理工具。参见：

《鸿蒙PC的包管理工具 Homebrew 正式上线，Harmonybrew介绍及使用指南》

《Harmonybrew（Homebrew 的鸿蒙移植版本）已正式上线》

或者可以从源码构建一个，刚好拿来作为移植案例素材练手，这也是本文的目的，将微软的 edit 轻量级终端编辑器带到 OpenHarmony。

移植过程

1. 环境准备（Ubuntu24的x86_64的linux系统环境）

需要交叉编译，Rust环境搭建参见 《OHOS (OpenHarmony) 鸿蒙的Rust 交叉编译环境搭建指南
》

安装 OpenHarmony SDK 后，NDK 中包含了 LLVM 工具链和 sysroot：

/root/ohos-sdk/linux/native/llvm/
├── bin/  (clang, lld 等)
└── sysroot/
    └── usr/
        ├── include/
        └── lib/
            ├── aarch64-linux-ohos/
            ├── arm-linux-ohos/
            ├── loongarch64-linux-ohos/
            └── x86_64-linux-ohos/

Rust 编译器已原生支持 aarch64-unknown-linux-ohos 目标：

rustc --target aarch64-unknown-linux-ohos --print cfg
# target_os="linux"
# target_env="ohos"
# target_family="unix"
# unix

2. 配置交叉编译

在项目根目录创建 .cargo/config.toml，指定链接器为 OHOS NDK 的 clang：

# .cargo/config.toml
[target.aarch64-unknown-linux-ohos]
linker = "/root/ohos-sdk/linux/native/llvm/bin/aarch64-unknown-linux-ohos-clang"

3. 核心修复：timespec 字段类型

遇到的问题是在 OHOS 上编译时，libc::timespec 结构体的 tv_sec 字段类型不是 libc::time_t，而是 libc::c_long。

原始代码（crates/edit/src/sys/unix.rs）：

#[cfg(target_os = "linux")]
{
    let ts = libc::timespec {
        tv_sec: timeout.as_secs() as libc::time_t,   // ← 编译错误
        tv_nsec: timeout.subsec_nanos() as libc::c_long,
    };
    ret = libc::ppoll(&mut pollfd, 1, &ts, std::ptr::null());
}

由于鸿蒙的 target_os = "linux" 会匹配 #[cfg(target_os = "linux")] 分支，走 ppoll 路径。但在 OHOS libc 中，timespec::tv_sec 被定义为 c_long 而非 time_t，导致类型不匹配。

修复方式：

#[cfg(target_os = "linux")]
{
    let ts = libc::timespec {
        tv_sec: timeout.as_secs() as libc::c_long,   // ← 改为 c_long
        tv_nsec: timeout.subsec_nanos() as libc::c_long,
    };
    ret = libc::ppoll(&mut pollfd, 1, &ts, std::ptr::null());
}

这一改动在 Linux（glibc/musl）上同样安全：主流 Linux 目标中 time_t 与 c_long 宽度相同（64 位），不会引入兼容问题。

4. 验证编译

cargo check --target aarch64-unknown-linux-ohos

编译通过，无额外报错。

为什么不需更多改动？

考察点	结论
target_os = "linux" 匹配	OHOS 的 target_os 就是 "linux"，所有现有 cfg(target_os = "linux") 分支自动生效
target_family = "unix"	libc 依赖、mmap/poll/read/write/signal 等系统调用均走 unix 分支
Cargo 条件依赖 cfg(unix)	正确拉取 libc crate
终端 I/O (tcgetattr/tcsetattr)	OHOS libc 实现兼容 IEEE Std 1003.1，行为与 Linux 一致
信号处理 (SIGWINCH)	完全兼容
ICU 动态加载	在 .cargo/config.toml 预留了 EDIT_CFG_ICUUC_SONAME 和 EDIT_CFG_ICUI18N_SONAME 环境变量，后续在 OHOS 上运行时按需启用即可

整个移植改动量仅为 1 行代码 + 1 个配置文件。

构建产物

编译得到的二进制可直接在鸿蒙 PC（ARM64）的终端中运行：

# 在 OHOS 设备上
./edit some_file.txt

支持语法高亮、多光标编辑、LSP 集成等全部功能。

延伸思考

1. ICU 支持：如需在 OHOS 上支持 ICU 国际化库，需将 .cargo/config.toml 中注释的 EDIT_CFG_ICUUC_SONAME / EDIT_CFG_ICUI18N_SONAME 放开，并确保 OHOS 系统镜像中包含 libicuuc.so / libicui18n.so。

2. LoongArch 支持：OHOS 也支持 loongarch64-unknown-linux-ohos 目标，LoongArch 的 libc 同样可能有类似 time_t 差异，修复方式一致。

3. CI 集成：可在 GitHub Actions 中添加 OHOS 交叉编译 workflow，借助 OHOS SDK 官方 Docker 镜像完成构建。

总结

OpenHarmony 的 Linux 内核兼容性 + Rust 生态的原生支持，使得将成熟的终端工具移植到鸿蒙 PC 非常顺畅。本项目中仅需修复一处 libc 结构体字段类型不匹配，其余 Unix 代码全部直接可用。希望这能为更多 Rust 项目移植到鸿蒙 PC 提供参考。

更多交流学习，欢迎加入开源鸿蒙PC社区：https://harmonypc.csdn.net/