[Markdown 编辑器] Blank for macOS 开始 Alpha 测试

[yeemn]

开头的话

独自一人的工作状态给了我许多做产品的想法，但又经常在一次深思后失去了兴趣，或者在一段脱离了工作的时间后，再回过头来看，那些想法就显得有些稚嫩或只是空想出来的使用场景。

这个编辑器的构思和开发从去年十月份开始，我做了一个比较完整的架构，但一个人的开发导致效率着实有些缓慢，所以三个月之前，我移除了大部分与编辑器无关的功能，如文档库，标签，版本管理等，因为这些功能在实现闭环之前所能带来的使用体验并不算好。在许多次大大小小的改动之后，这个编辑器终于开始有了一些可用性。

这个编辑器将会是一个付费应用。

介绍

这是一个性能优先的 markdown 编辑器，可以轻松的处理庞大的文档。

这是一个简洁优先的编辑器，排除干扰，专注于写作，当然简洁的另一个意思就是简陋，所以这也是一个相当简陋的编辑器，除了写作以外，目前还没有任何其他功能，没有图片预览，没有表格渲染和高亮。

测试的目的和重点

由于性能要求，这个编辑器的排版、编辑和滚动功能都是自定义实现的，我希望在确定了这些基础功能的稳定性之后，再去拓展一些高级功能。

如你所见，目前为止，这只是一个编辑器。

一些额外说明

markdown 解析和展示

关于 markdown 格式我尽量参考了 commonmark 和 github-gfm 的标准，但并未实现全部的格式，如注解，表格，删除线等都暂未实现。需要特别说明的是，我一直以来习惯使用单回车换行，也不太理解双回车的必要性，所以在解析过程中是以单回车作分割标准的。虽然对于当前版本只有格式高亮功能的纯文本编辑器来说，没什么区别。

没有图片预览功能

显示图片会导致排版的混乱，对于一个纯文本编辑器来说，这会在使用过程中产生割裂感，正如异步格式渲染及因此引起的文字的位置、格式、样式变动以及光标跳动一样，这些处理方式都会破坏使用时的感觉。

表格的处理方式

这是一个使用 Swift 开发的编辑器，渲染表格确实有点难为我了。我有一个还未验证的处理思路，但这不是目前开发的重点。在验证这个思路的可行性之前，我没有为表格提供格式高亮及任何便利性操作的计划。

滚动

当前的滚动实现了与屏幕相同的刷新率，但速度的加速和衰减曲线还没有仔细调教，如果你对此有深入的了解的话，欢迎给出建议。

另外，我没有触控板和 Magic Mouse 等设备，所以这些设备可能拥有的针对滚动的优化，当前版本都没有支持。如果你正在使用这些设备，或对这些设备的滚动操作有了解，也欢迎给出建议。

测试信息

当前版本使用 App Center 框架收集崩溃信息，由于 App Center 暂未支持 Sparkle，所以应用的测试版本分发在 HockeyApp 中进行。Alpha 版本测试地址为 rink.hockeyapp.net/apps/c34ecef94d6143b99a72f171d1f6286b

由于测试版本可能存在的各种导致应用崩溃的异常，请勿用来编辑特别重要的文档。

对于应用使用过程中的任何反馈，你都可以通过 HockeyApp 测试页面 Feedback 功能来发送，之后我也许会在 GitHub 上建立一个用于反馈的仓库，如果你觉得有更好的方式来处理和追踪测试，欢迎推荐。

最后，希望你能够有愉快的使用体验。

我在 Github 上创建了一个用于后续追踪 BUG 和反馈的仓库：github.com/yeemn/Blank-Issues，欢迎反馈。

[yeemn]

Alpha 版本测试地址为 rink.hockeyapp.net/apps/c34ecef94d6143b99a72f171d1f6286b

[jedrek]

有做成笔记带分类目录带计划吗 ？

[tsohgdivil]

这个编辑器的亮点在哪？性能很好？

[yeemn]

@tsohgdivil 目前来说，是这样的。

@jedrek 当前的第一优先级为编辑功能，接下来是自定义样式的格式导出，然后是文档库的管理与同步。

[blaaibla]

加油。现在我使用过的 markdown 工具中，感觉的确在"处理庞大的文档"上不怎么给力。Notion 做得比较好，但在处理大量的表格数据也是卡得难受。不过现实中，极少有人去写庞大的 markdown 文件吧？

[ipwx]

巨大的 Markdown 文档在现实中基本不是需要考虑的需求。

如果有，就拆开来写，然后 pandoc 合并就能随意渲染成任何输出格式。

[yeemn]

@blaaibla

@ipwx “能够处理庞大的文档”是追求 **流畅使用** 所需要和所产生的结果中的一环，而不是直接目的。

[jamesxu]

程序员通常会花几年时间苦苦寻找理想的 RSS 阅读器和 Markdown 笔记软件，伴随着无数次想自己动手写一个的冲动。 #工程师的日常

—摘自 TG

[yeemn]

@jamesxu 我当初开发（未果）的第一款软件就是一个 RSS 阅读器。

[airyland]

@jamesxu 这是我在即刻写的。。

[yeemn]

@airyland 厉害了，我第一次看到这句话就是在即刻。

[hkongm]

特地装了一个，试了下，没看出亮点在哪里，还需要再打磨，楼主加油

[lijixi]

如果这个编辑器不能超过 VSCode （非即时渲染）和 Typora （即时渲染），那它几乎没必要存在，何况还收费。祝愿您的软件能够比它们强。

[szzhiyang]

「显示图片会导致排版的混乱，对于一个纯文本编辑器来说，这会在使用过程中产生割裂感，正如异步格式渲染及因此引起的文字的位置、格式、样式变动以及光标跳动一样，这些处理方式都会破坏使用时的感觉。」

身为一款付费 Markdown 编辑器的开发者，竟然如此堂而皇之地给自己的敷衍和懒惰找借口，谁给你的勇气？

[yeemn]

@lijixi 如果是性能的话，目前来说是要比 vscode 要好的，因为只计算了本页内的排版，而且使用了 Swift 原生开发及做了较多优化，内存占用也比 vscode 及相同类型的软件小一些。我最开始的时候的写作就是使用 vscode 的，但单作为 markdown 编辑器来说，它的启动速度令人崩溃，也有很多地方不如意。而 typora 的这种处理方式我并不喜欢，就如同我说的「这些处理方式都会破坏使用时的感觉。」。渲染完成的格式在需要重新编辑时又变化成格式代码，文字内容，光标位置，段落排版都在变，用起来实在难受。

@szzhiyang 我的这款软件是基于 Core Text 开发的，我很简单就可以加上如 typora 那样的渲染效果，但正如我上面所说，这种处理方式并不好。而且图片渲染我在之前的版本中也尝试实现了，但实际使用的效果并不好，尤其是在 markdown 这种为了弱化排版而产生的需求下。在段内与文字共存时，图片拉长了行高和光标长度，对于写作者而言并无太大的意义，还会在写作时产生干扰。相比较而言，Ulysses 处理图片的方式还算好，只在单独一段时显示，但这种处理方式仍然不算太好。所以在我没有想到一个更好的处理方式之前，这就是我对待 markdown 中图片格式的态度。
最后，我的勇气来自于我的认真，谢谢。