严格来说，这并不是完全从零自制的，标题多少有一点“标题党”。
这个项目基于 KDE 开源的 Markdown 编辑器 ghostwriter 进行修改。原项目地址如下：
ghostwriter 本身已经是一款相当成熟的 Markdown 编辑器。我主要是在原项目的基础上，根据自己的实际使用需求进行了一些功能调整和二次开发。与其说是“自制”，更准确的说法应该是：我给自己魔改了一款更顺手的 Markdown 编辑器。
为什么需要一个 Markdown 编辑器？
最近需要编写的 Markdown 文件越来越多。
除了普通的项目文档以外，Codex 的提示词、Agent 配置、Skill 说明，以及各种工作流程和技术记录，基本都需要通过 Markdown 文件进行维护。随着文件数量增加，我对编辑工具的要求也逐渐明确：
- 文件需要保存在本地
- 必须能够方便地读取和插入本地图片,支持多种路径
- 编辑体验要足够轻量
- 拥有实时预览
- 不要干扰现有的代码开发环境
我之前也尝试过一些常见的工具。
有道云笔记本身很好用，跨设备同步和在线编辑都很方便。但它首先是一款以“云端”为核心的笔记工具，主要使用场景仍然偏向线上内容管理。对于需要直接操作本地Markdown文件、本地目录和本地图片的工作流来说，它的体验并不理想。尤其是在读取本地图片、维护相对路径以及管理本地文件结构时，整个流程比较别扭。对于普通笔记来说，这些问题可能并不明显，但一旦涉及 Agent、Skill 或项目文档，就很容易增加额外的整理成本。感觉和Codex生态不是很搭配。
Visual Studio Code 当然也可以编辑 Markdown，而且很好地解决了本地文件管理的问题。无论是目录结构、版本控制，还是 Markdown 插件生态，VS Code 都已经足够完善。
但我一直希望代码工作区能够保持干净、清晰。
代码、资源文件、提示词、个人笔记和长篇说明文档如果全部混在同一个编辑器里，很容易让工作区变得杂乱。虽然从功能上来说，VS Code 完全能够承担这些任务，但我不希望所有工作都挤在同一个软件中。我真的很烦开特别多同一个软件的窗口..
我需要一个相对独立的写作环境，将“编写代码”和“整理文档”隔离开来。
这种隔离并不是因为 VS Code 不够好，而是因为不同类型的工作需要不同的注意力模式。写代码时，我希望关注工程结构、逻辑和调试；写文档时，我更希望专注于内容、表达和信息组织。
找到 ghostwriter
带着这些需求，我开始在 GitHub 上寻找合适的 Markdown 编辑器，后来发现了 KDE 的 ghostwriter。
使用一段时间后，我发现它基本符合我的预期：
它以本地文件为核心，界面足够轻量，同时提供 Markdown 编辑和实时预览。相比功能复杂的笔记平台，它更接近一个纯粹的写作工具；相比完整的集成开发环境，它又不会带来过多与写作无关的界面和功能。
整体使用体验已经很好，但在 Windows 环境下，它仍然存在几个影响我日常使用的问题。
原版中遇到的几个问题
1. 输入法候选框位置异常
我遇到的第一个问题是中文输入法候选框的位置异常。
在编辑文字时，输入法候选框不会出现在当前光标附近，而是始终显示在窗口左上角。这会导致视线不断在正文和屏幕左上角之间移动，长时间输入中文时非常影响体验。
我查阅了一些相关信息，发现 Linux 版本似乎处理过类似问题，但我使用的是 Windows。后来尝试调整了多个与输入法和窗口定位有关的接口，最初都没有取得理想效果。
这类问题看起来只是一个小的界面瑕疵，但对于以文字输入为核心的软件来说，候选框能否正确跟随光标，实际上会直接影响编辑效率。
2. 编辑区与预览区不能同步滚动
ghostwriter 的编辑区和预览区支持通过标题进行定位。点击对应标题后，两侧内容可以跳转到相应位置。
但这并不是我真正想要的交互方式。
我更希望编辑区和预览区能够根据当前阅读位置持续同步滚动：左侧编辑到哪里，右侧预览就跟到哪里；拖动右侧预览时，左侧也能够定位到对应的 Markdown 内容。
对于较短的文档来说，标题跳转已经基本够用。但面对篇幅较长、标题层级较多的技术文档时，仅依靠标题定位仍然不够直观。
特别是在调整段落、检查图片位置或修改局部排版时，同屏同步滚动能够明显减少来回查找内容的时间。
3. 不支持直接拖入文件和图片
第三个问题是文件和图片的拖放体验。
原版并不支持按照我的预期，直接将本地文件或图片拖入编辑区域。对纯文字写作来说，这可能不是一个严重的问题，但我的很多文档都需要配合图片才能完整表达。
例如：
- Agent 或工具的操作界面；
- 节点结构和流程示意图；
- 程序运行结果；
- 美术效果对比；
- Bug 复现截图；
- 参数配置说明。
如果每次插入图片都需要手动复制文件、整理目录、查找路径，再编写 Markdown 图片语法，整个过程会产生很多重复操作。
我希望编辑器能够主动完成这些机械步骤：接收拖入的文件，将图片放置到合适的位置，并生成可以直接使用的 Markdown 引用。
我修改了什么？
针对上述问题，我在 ghostwriter 的基础上进行了修改，主要完善了以下功能：
输入法候选框跟随光标
我调整了 Windows 环境下输入法候选窗口的定位逻辑，使候选框能够尽可能跟随当前文本光标显示。
这样在输入中文时，视线可以始终停留在正在编辑的内容附近，不需要再频繁查看窗口左上角。
这个改动从功能上看并不复杂，却是几项修改中体感最明显的一项。对于中文用户而言，输入法交互本身就是编辑体验的重要组成部分。
编辑区与预览区同步滚动
我补充了编辑区与预览区之间的滚动同步逻辑。
现在查看长篇 Markdown 文档时，两侧内容能够更加稳定地对应。无论是编辑正文、调整图片，还是检查最终排版，都不再需要频繁依赖标题跳转。
同步滚动真正困难的地方并不是简单地让两侧拥有相同的滚动条数值。Markdown 源文本和最终渲染结果的高度通常并不一致：标题、图片、代码块和列表经过渲染后，都会占据不同的空间。
因此，更合理的处理方式是建立源文本位置与预览内容位置之间的对应关系，而不是机械地同步滚动百分比。
支持拖入文件和图片
我还增加了拖放相关的处理。
现在可以将本地图片或文件直接拖入编辑区域，由编辑器生成相应的 Markdown 内容。对于需要大量使用截图和效果图的技术文档来说，这项功能能够减少很多重复操作。
我的目标并不是把编辑器改造成一个复杂的资源管理工具，而是让“把图片放进文档”这件事变得足够自然：拖进去，然后继续写。
演示
开源地址
我已经将修改后的版本开源到 GitHub，欢迎有类似需求的朋友下载使用，也欢迎提交 Issue 或参与改进。
我的修改版：
最后再次感谢 ghostwriter 原作者及 KDE 社区的开源贡献。我的版本是在原项目基础上进行的二次开发，并不是完全从零实现的独立编辑器。
