这是一篇脑洞文，请不要信以为真，现实中不存在这样的编辑器！
相关的文章：
反Markdown试验：用Markdown的思维来使用Word
这篇文章是以上三篇文章的逻辑终点——当我们焦点不停游移在Markdown与非Markdown之间，最后会结出怎样一个果实？
之前看了一篇文章重新想像 Excel 该有的样子：Airtable 评测，提到一个现代化网络服务（包括软件）应该具有具有三点实质：
目前很多优秀的Markdown编辑器已经完全符合上面的3个特点，但是在非Markdown领域，很少有编辑器能符合上述的特征，更不可能够达到Markdown编辑器目前的高度。像Matcha那样愿意进行突破的毕竟是少数，更何况Matcha只是个IOS应用。大公司的富文本编辑器（如Word）不是面向内容，而小作坊的富文本编辑器功能上还没有一般的Markdown编辑器丰富。于是我萌生了这样一个想法，如果用Markdown的思维去设计一款富文本编辑器，那么它将会是什么样子呢。
现在的编辑器给了我一个很大的提示：其实源码输入与所见即所得的边界很模糊，并非我们想象的那么泾渭分明。如果我们在源码输入与所见即所得两者之间话一条线，再将不同的编辑器放进去，我们会得到下面的图：
再看看目前的用户体验比较好的编辑器，其实大部分都集中在两者之间，靠近所见即所得这头。Markdown编辑器的发展是从源码输入出发，向所见即所得靠近。如果我们反其道而行之，以所见即所得出发，向Markdown靠近，相信会得到一个很有趣的结果。
所以我的设计理念是：将Markdown以及Markdown编辑器的特性揉进一款非Markdown编辑器中。
好了，下面进入正题。
首先这款编辑器的定位非常明确：面向多终端，面向网络书写，面向普通用户。
在我看来Markdown再容易写，它都带有一些极客的味道，因为它面向普通用户，所以我希望可以这款编辑器可以用非极客的方式呈现。
我相信这样的定位非常符合一开始所提到的3点特点。
这款编辑器是为书写内容而设计，它应该具有Markdown编辑器时的书写体验：
另外它也应该具有Markdown语言的一些优点：
一定不会选择Markdown作为保存文档的格式，因为Markdown不是一种发布语言，它只适合书写，关键是它不严格。Markdown是方便书写用的，如果不用Markdown来书写却用它来作底层格式，这样显然是本末倒置的。而且我们这个编辑器是非Markdown编辑器（笑）。一款Markdown编辑器与一款非Markdown编辑器的根本区别在于Markdown编辑器使用Markdown作为文档的保存格式，而非Markdown编辑器不是。在操作层面，二者只会越来越雷同。所以不会选择Markdown。因为考虑到内容与形式分离，HTML或XML或许是个不错的选择。
这款编辑器是面向内容的，它要求内容与形式分离。就如同Markdown一样，我们可以事先对样式进行预设，也可以在书写完内容之后对文章进行样式调整。面向内容也意味着，它会像众多Markdown编辑器一样，排版功能相对较弱。强大的排版功能是不会有的，也不需要有。因为书写的内容需要适应多终端。书写好的内容无论在手机还是电脑都应该很好的显示，就像我们阅读epub电子书一样会更具不同的屏幕自适应，这样才能更好的在人与人之间、设备与设备之间传递。当我们在Word中书写时，我们是预设好一张A4纸，让后将内容都放上面，这样对排版很好，但是不适合网络书写。网络这张纸是弹性宽度，无限长度的。为了适应手机端，内容的结构也应该像Markdown内容一样采用纵向排列，不允许横向排列。现在的HTML编辑器都不是内容与形式分离的，但其实实现起来并不难。
Markdown的语法可以分成区块元素与行内元素，而区块元素又可以分成可嵌套区块和不可嵌套区块。
这里采用类似Markdown的划分，也将内容分成区块元素与行内元素（为了方便说明，我决定将区块元素简称区块，行内元素简称部件，下同）。不过与Markdown不同的是，表格被作为可嵌套区块，这样就解决了Markdown中输入表格难的问题。另外本人认为将图片作为区块更合适，因为目前图片很少会直接出现在段落中间，不如作为区块来得直接。另外，将部件分成样式部件和内容部件。样式部件用于为一定量的文字提供样式，内容部件主要是直接充当内容。具体的分类如下：
另外，这款编辑器允许强制换行，一般回车会得到一个新的段落，但是我们还是允许使用Shift+回车进行段落内的强制换行。这个概念是从HTML和Markdown中继承的，虽然在实际中使用不多，但是在一些情况下使用会很有帮助，比如写一首诗。这种连续的短句如果都分成段落，显示上会不好看，所以我们保留了强制换行的概念。一般的所见即所得编辑器是没有这个概念，如果你想写一首诗，只能最后去的调整段间距或者使用文本框。加入这个概念也会让Markdown用户和HTML用户更加适应。
当然，不允许强制换行，而是增加文本框区块来实现同样功能也是可行的。
这里所说的结构不是排版范畴的结构，而是指内容之间的相互关系。具体说可以分成两部分：
因为区块在文章中是纵向排列的，区块的前后关系就是上下的排列顺序。而嵌套关系主要针对可嵌套区块，在Markdown中主要指引用和列表，这里加上表格。它都可以嵌套所有的区块，包括自身，列表嵌套列表就产生了多级列表，以此类推。
这些结构关系在Markdown语法中都能够得到体现，但是经常没有受到编辑器的重视。在Markdown编辑器中，我们可以很方便的识别各种结构，这个得益于Markdown语法，在Markdown中各级标题有#号区分，区块之间有空行区分，列表嵌套有Tab，但是在Markdown编辑器中对结构进行调整时就不容易。首先很难选择这个区块，如果希望调整区块的上下关系，只能自己将区块选择剪切粘贴。而在所见即所得编辑器中，结构问题更加严重。虽然Word这样的编辑器提供了大纲试图，但是不好用。而且在所见即所得编辑器中，我们有时候不好区分结构，比如不同级的标题如果不借助大纲，有时候分不出来。
所以我希望这个编辑器拥有很丰富的结构调整功能，包括：
标题识别。对标题进行特殊的标识，就像Markdown的标题前有井号#一样，或者进行高亮，最好还可以对标题下的内容进行折叠。
标题管理。对各级标题进行专门的管理，可以很方便实现以下功能：修改标题的内容、调整标题的级别、调整标题的顺序（所包含的区块会跟随标题移动）、自动加入章节号、修改章节号的样式。对于将内容分开书写，最后合并的情况，这些很有用。
区块调整：快速选择单个区块，调整区块的上下关系，调整列表的所嵌套的区块间的层级关系和上下关系。最好可以很直观地区分每个区块以及他们层级关系。像TinyMCE就提供了一个叫“Show Blocks”的功能，将每个区块用方框显示出来。这是个很好的思路，如果在调整区块的时候可以显示周围相关的区块的边界，那么会更方便。
在我们可以经常看到人们使用所见即所得编辑器进行书写的时候，会使用空格、空行进行排版。比如希望首行缩进的时候，可能会在首行添加两个空格而不是在标尺上进行缩进，也会常常用空行来调整两个内容之间的距离。这些都是不良的书写习惯。在面向内容书写的时候，段落前后的空格空行都是多余的，只会造成不必要的混乱。所以，在Markdown中不会显示段落前后的空格空行，而是将空格空行作为语法的一部分来规范内容。所以这个编辑器也采用了类似的：不允许空行，不允许段落前空格。
同样，这款编辑器也不允许空白的部件和区块，因为没有内容填充的部件与区块是没有意义的。
因为没有空行来调整书写时的视觉焦点，所以相对的，编辑器会根据光标位置自动调整视觉焦点，类似专注模式。
区块的显示：采用所见即所得的显示方法。
部件的显示：
链接、代码、公式等内容部件采用所见即所得的显示方法。
样式部件，包括加粗、斜体、删除线等等：这里会先给文本添加相应的样式，同时在文本两端各生成一个范围标识将其包裹。这样做法其实非常类似Markdown，它可以吸取Markdown这方面的优势，包括：
设计一款所见即所得编辑器的最大难度在于怎么让用户拥有畅快的书写体验，所以这一部分的设计是重点也是难点。如何畅快书写的重点其实是如何快速添加部件和区块，最后结束它们。至于文字的录入，那是输入法的领域。因为文字录入主要依靠键盘，所以一种畅快的输入体验必然是尽可能依赖键盘完成，这样我们就无需在键盘与鼠标之间进行来回的切换。频繁的键盘鼠标切换正式所见即所得编辑器的书写体验差的直接原因之一。为了尽可能放弃鼠标的参与，在这里我设计了三种方法，以向优秀的Markdown编辑器（比如Typora）致敬，分别是快捷键、便捷工具栏和语法输入。
快捷键在一般的所见即所得编辑器中是相对便利的做法，这款编辑器会为每个部件与区块添加快捷键，并且支持自定义。但是随着部件与区块种类的增加，快捷键的方式就会面临覆盖面与记忆的问题，而且快捷键可能还需要覆盖录入之外功能。有时候太多的快捷键可能还不如学习Markdown语法来的简单呢。所以我觉得应该需要一种学习成本更低的方法。
如果有更简单无脑的添加部件与区块的方法，那一定是很直观的，所以我想到了浮动工具栏。其实浮动工具栏就是很常见的做法，像是Wrod中选中一段文字之后会出现的工具栏一样，它是固定工具栏的延续，但是它离我们视觉焦点更近了，所以很便利。但是如何触发工具栏是个问题，因为不可能让工具栏一直跟随视觉焦点（光标），这样太影响书写。Word中是使用鼠标才能触发，不符合我们键盘录入的书写原则。那么键盘上的右键菜单快捷键呢，那个太臃肿了，应该把右键菜单更多的用在其他功能上，而且有的键盘没有右键菜单铵键。因为书写讲究的是快捷便利，所以这个触发键还要容易触按。想了想，符合要求的键也就只有F1、Tab和方向键，这些键都位于键盘的角落位置，容易触按。
这三者当中，如果考虑按键的占用，F1是最好的选择。但是在某些场景下，Tab与方向键的补充我觉得也是必要的，因为他们符合书写的顺性。Tab键目前主要是用于表格单元格的调整和列表的缩进（在一般富文本编辑器还用于段落的缩进，这里取消了），在这两个表格和列表之外，Tab也可以用于调出部件快捷工具栏。方向键一般用于光标的移动，当我们进行线性书写的时候，因为不允许出现空行，所以光标总是处于当前内容的最后一行最后一个字符后面，这样我们就可以将其利用起来。为了书写的顺性，右方向键对应在光标右方出现部件的工具栏，下方向键对应在光标的下方出现区块的工具栏。左方向键与上方向键仍然用于光标的移动。在不触按下和右方向键的时候，便捷工具栏应该被收起，仅在光标的右侧和下方做点提示。如果被触发，应该两个都出现，但是各有侧重，画了个示意图：
使用方向键的缺点很明显，只能使用场景过于单一，只能用于线性书写，不能用于修改。
因为不允许空行，如果在新行使用回车也会弹出区块便捷工具栏。
没错，你没有看错，这个编辑器可以使用语法输入！受了Matcha等编辑器的启发，我发现语法输入不是Markdown编辑器的特权。要注意的是，这里的语法输入不是真正意义上的兼容Markdown的语法，而是仅仅是使用特定的Markdown语法来完成添加部件或区块的动作而已，这个与Matcha编辑器就不一样了。比如当我们在行首输入```之后，自动添加区块代码框，我们可以直接在里面输入代码；又比如我们在行首输入>之后，自动添加引用，我们可以直接在里面书写；再比如在行首输入-，自动添加列表。怎么样？是不是跟Markdown相似又高效？
而且谁要求一定要兼容Markdown语法？这个完全可以自定义，我们将语法的设计权交给用户，这就规避了Markdown语法之间的差异，不需要担心方言和兼容性问题。如果你喜欢，甚至使用中文也是可以的。比如在行首输入表格，然后编辑器会弹出表格窗口；当我们在行首输入公式，编辑器会生成一个公式编辑器。这样的操作美不美？这样我们再也不用去记忆Markdown语法，再也不用去频繁地中英切换去输入Markdown语法，再也不用为ipad输入不了英文字符而操心了。当然，为了照顾Markdown用户，编辑器也会根据Markdown内置一套与之相近的配套语法。Markdown用户和非Markdown用户在这里可以握手言和了。
相对于快捷键，使用语法输入的优势在哪里？最大的原因不是因为语法输入会比快捷键快（实际情况可能快捷键更快），而是语法输入顺应了我们书写的惯性。我们一直在书写文字和字符，已经到了停不下来的地步——这就是畅快的书写体验。而且快捷键都是一种组合键，我想说使用组合键经常会遇到两个键同时使用左手的情况，这会有点别扭。可能是我的使用习惯不好，因为使用快捷键的时候，右手往往在使用鼠标，久而久之就成了习惯，所以即使平时书写时双手都在键盘上，也会因为习惯而用左手按快捷键。
对于样式（加粗、删除线等）的添加，跟使用Markdown编辑器的工具栏添加样式的情况类似，会生成一对范围标识，然后光标在标识之间。画了个示意图：
大概就是这么个感觉。我们知道，一般所见即所得编辑器添加样式的方法有两种：一是后处理，先书写需要的内容，然后选择内容添加样式；二是线性处理，预先选中样式，然后书写，最后结束样式。前一种方式破坏了书写的顺性，后一种方法因为没有明确的结束表示，容易忘记结束样式，到下一行再回头修改，而且需要按两次快捷键，就好像我们添加了两次样式一样，体验不好。其实使用Markdown书写的时候，中文环境下常常也有类似后者的体验。当我们添加斜体的时候先添加星号再书写内容最后以星号结束，这很符合书写的顺性。但是如果使用行内代码或者尖括号的时候，我往往是成对输入``、<>再将光标回调进两个符号中间。为什么这么做？因为这些符号只能在英文状态下进行输入，比起频繁切换，我宁愿成对输入，但这就造成了体验上的差异。既然如此，我们何不将所有部件书写体验统一起来呢，都生成一对标识然后光标在中间。结束样式方法，我也进行了不一样的设计——使用Tab或右方向键结束样式（一些情况，End键也可以），光标会自动调到结束标识的右侧。很多手机输入法（主要是中文输入法，苹果例外）插入括号都是成对输入的，与此类似。所以如果有移动端，这种书写体验也是可以被带到移动端的，非常自然，不会造成Markdown编辑器那种移动端与桌面端那种体验落差。
行内公式和行内代码的结束都跟样式部件类似，采用Tab或右方向键结束样式。而区块的结束使用回车，只输入一次回车可能只会得到同一个区块的延续，这时候再一次回车就行。对于表格，可能使用Tab来结束更加好。
优秀的书写体验必然也体验在内容修改上，我们在书写时出现问题往往及时的修改。内容修改是所见即所得编辑器的长处，却是Markdown编辑器的弱项，这也是为什么Markdown编辑器越来越像所见即所得编辑器的原因之一。在修改内容的时候，对于纯键盘的需要会大大降低，而因为鼠标的加入，按钮、快捷键、右键菜单都是很好的选择，这些操作在一般富文本编辑器很常见，不做介绍了。另外我的体会是，如果书写内容完成后再修改，这种修改往往是跳跃式的，这种修改鼠标配合键盘更合适。当时如果是在书写当中出现了错误操作，需要修正，这种小修改如果能使用键盘会更好，所以我设计所有的小修改都应该有相应的纯键盘方案。
Ctrl+方向键就可以修改范围。Alt+方向键进行位置移动。这种方法也适合单纯文本的移动。在区块的修改在“内容的结构”部分简单做了一些说明，这里详细说一下：
Alt+方向键就可以进行结构调整。区块种类的修改：部分区块允许进行种类的转换，这个主要是为了适应所见即所得编辑器的智能输入。智能输入是所见即所得编辑器与Markdown编辑器的区别之一，比如我们编辑一个列表，在Markdown中，每一次回车我们只会得到一个新的空白行，需要我们自己重新缩进和添加列表项目标识。而在一般的所见即所得编辑器，回车会得到一个同级的列表（不过目前有的Markdown也能支持部分智能输入，比如自动缩进）。Markdown的方法略繁琐，但是结束的时候方便。而所见即所得编辑器的方法虽然方便，但是结束麻烦，最大的问题在于它很难进行嵌套内容的书写。每一次回车只会得到一个列表项目，万一我需要的是一个段落呢？这是一般富文本编辑器的难题。所以我们允许对区块进行转化，其实主要就是针对列表和段落之间的转化，因为这种情况在我使用过程中很常见。方法是光标移动到区块标识处会出现菜单，进行选择就可以。键盘方案：用第2点的方法选中区块标识，会出现菜单，进行选择即可。
其实还有一种简单的思路，就是像Markdown一样，让用户每一行都自己去定义区块（但是保留缩进），但是我个人比较喜欢智能输入，所以这种Markdown式的方法只能作为备选。在条件允许的情况下，最好可以两种方法都加入，让用户自己去选择。
区块的删除：只要选中标识，Delete。
这里所说的拓展性只要指内容的拓展，不是指软件功能的拓展（其实如果部分功能以功能模块的方式呈现，允许插件的话，这种软件拓展性也是很强的）。就像Markdown语法可以被不断加入新的元素一样，编辑器未来也可以根据需要加入新的部件和区块，比如流程图、附件、文本框之类，以便适应不同的需求。因为对了部件和区块进行了严格区分，所以加入的功能也会被进行分类，这样就可以避免了一般富文本编辑器中功能的随意性。在一般富文本编辑器中，是混淆部件与区块的，比如代码功能只有一个按钮，这样用户就会出现理解上的混乱。
另外，软件会允许用户根据需要创建一些样式部件，不实现上可能有些难度，还需要建立宏。
这个编辑器应该很容易地兼容Markdown与HTML格式，这里的兼容不是指在书写时允许添加它们的语法，而是指很方便对它们进行导入导出，因为在文章框架上（区分部件与区块），它们之间是很相像的，只是具体功能上的差异。Markdown有严重的方言问题，我反复告诉自己，Markdown只是一种书写语言，不是一种发布格式，但是对Markdown格式的支持（导入导出）是很有必要，谁叫它实在太火了。当然兼容所有Markdowny语法是不可能，所以编辑器只会兼容一些常见的语法，比如原生语法和GFM，但是也允许用户对语法表进行修改从而可以兼容部分其他的Markdown语法。HTML因为是一种规范语法，所以不用过于担心。
其实最早我是想将其设计成针对笔记书写的编辑器，因为目前笔记软件（比如印象笔记）的编辑功能都太弱，而Onenote虽然编辑功能强大，但是画布式的编辑让我不能接受。Bear其实是目前笔记软件中最好的书写体验最高的，可惜不支持表格。目前的笔记软件对附件支持不好，附件应该作为文章的一部分而不是像电子邮件一样被搁置一旁，稍微好点是为知笔记，允许将附件作为文章一部分插入笔记中，但是体验不好。而且我认为笔记跟普通的内容展示不太一样，它首先是方便作者自己阅读的，所以阅读试图下应该允许一下简单的交互，文章内部跳转、打开图片放大查看、打开附件，甚至是对部分附件的预览，这就很像一个真正的网页。目前的笔记软件很难做到这些东西，所以我就想如果自己来设计会怎么样。后来我发现其实不必把眼光盯在笔记的书写上，这样目光太短浅。一款良好的编辑器器完全可以做到更多，它甚至可以成为一个书写系统和平台，为不同网络需求的提供完整书写解决方案。当编辑器拥有足够的部件和区块，我们就可以让用户根据需要进行部件和区块的选择，定义输出的格式，最后打包成一个情景模式。比如为知笔记允许HTML的书写，那么我们的就可以将一份HTML中可能用到的功能（部件和区块）挑选出来，生成成一个适合“为知笔记”书写的情景模式，以后只要进入情景就可以。
在Mac中因为有Multi-Touch Bar的存在，所以可以让很多功能更方便的实现，展望一下。
移动端因为规避了中英切换问题，加上部件和区块的添加方法，所以移动端与桌面端体验上的差异会大大缩短，这就跟Markdown编辑器拉开了距离。移动端为了方便会提供很多手势，就像Matcha一样。
这是场脑内试验，就像爱因斯坦所做的一样，俗称“YY”，所以这款编辑器实际上是不存在的，它只是一个概念，什么没有一个正式的名字，姑且称为“概念编辑器”。但是这款概念编辑器是面向未来的，我相信我在里面设计的一些功能未来会在一些其他编辑器中出现，比如拖动修改样式部件范围。但是如果有人发现了类似的编辑器，请告诉我！
另外，因为篇幅关系，有些问题我没有来得及讨论。比如样式部件的改造，在原生Markdown语法中，“ * ”对应“ <en> ”标签，而不是“<i>”标签，它是有语义的，而不是简单地把内容变成斜体。所有的样式部件都应该改造成基于语义的，用于内容定义和内容区分，只有这样才能实现真正的内容形式分离。简单添加样式不是真正的内容形式分离。未来有机会我们再讨论这些问题。
最后，由于本人不是程序员，完全不会编程，所以这款编辑器不会出自我手。但是如果有一天，这款编辑器能够真正的呈现人间，我相信是一件非常欣喜的事情。所以谁快来实现我的想法吧！
如果有一天真的出现了类似的编辑器，欢迎来挖坟。
欢迎大家互相交流。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。