鸿蒙 PC 移植记：将微软的 `edit` 轻量级终端编辑器带到 OpenHarmony
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中执行以下命令安装wingetinstallMicrosoft.Edit#或者从github上下载：wgethttps://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）。
brewinstallmsedit强烈推荐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--targetaarch64-unknown-linux-ohos--printcfg# target_os="linux"# target_env="ohos"# target_family="unix"# unix2. 配置交叉编译
在项目根目录创建.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")]{letts=libc::timespec{tv_sec:timeout.as_secs()aslibc::time_t,// ← 编译错误tv_nsec:timeout.subsec_nanos()aslibc::c_long,};ret=libc::ppoll(&mutpollfd,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")]{letts=libc::timespec{tv_sec:timeout.as_secs()aslibc::c_long,// ← 改为 c_longtv_nsec:timeout.subsec_nanos()aslibc::c_long,};ret=libc::ppoll(&mutpollfd,1,&ts,std::ptr::null());}这一改动在 Linux（glibc/musl）上同样安全：主流 Linux 目标中time_t与c_long宽度相同（64 位），不会引入兼容问题。
4. 验证编译
cargocheck--targetaarch64-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 集成等全部功能。
延伸思考
ICU 支持：如需在 OHOS 上支持 ICU 国际化库，需将
.cargo/config.toml中注释的EDIT_CFG_ICUUC_SONAME/EDIT_CFG_ICUI18N_SONAME放开，并确保 OHOS 系统镜像中包含libicuuc.so/libicui18n.so。LoongArch 支持：OHOS 也支持
loongarch64-unknown-linux-ohos目标，LoongArch 的 libc 同样可能有类似time_t差异，修复方式一致。CI 集成：可在 GitHub Actions 中添加 OHOS 交叉编译 workflow，借助 OHOS SDK 官方 Docker 镜像完成构建。
总结
OpenHarmony 的 Linux 内核兼容性 + Rust 生态的原生支持，使得将成熟的终端工具移植到鸿蒙 PC 非常顺畅。本项目中仅需修复一处 libc 结构体字段类型不匹配，其余 Unix 代码全部直接可用。希望这能为更多 Rust 项目移植到鸿蒙 PC 提供参考。
更多交流学习，欢迎加入开源鸿蒙PC社区：https://harmonypc.csdn.net/