html markdown写笔记,谈谈为知笔记的Markdown功能

这文章属于专题的一部分,详见:Markdown知识贴

下面谈谈为知笔记(简称“为知”,下同)中的Markdown功能,包括为知Markdown支持的语法,Markdown功能的实现,目前已知的问题和对为知Markdown的展望等方面。

为知Markdown支持语法

根据为知的Markdown说明和简单测试,为知目前支持的语法有

区块元素标题(Setext式和Atx式)

段落

区块代码(缩进式和围栏式)

技术绘图(流程图和时序图)

区块公式

简单表格

分割线

区块引用

列表(无序和有序)

目录

行内元素链接(行内式、参考式和自动链接)

图片(行内式和参考式)

强调与重强调

删除线

行内代码

行内公式

脚注

为知对Markdown的改进

为知允许用户直接复制或拖动插入图片,和用自带的编辑器插入图片和表格,希望用这种方式来弥补Markdown文档自身对本地图片与表格的缺陷。这个看似很多编辑器都在支持的功能,但是为知这种方式得到的Markdown文档无法与目前可见所有Markdown编辑器兼容。

为知Markdown的实现

为知的Markdown与一般的Markdown有很大的不同,这产生了很多奇妙的现象:

为知的Markdown笔记与普通笔记共用一个编辑器;

Markdown笔记打开时总是要闪一下;

使用外部编辑器打开Markdown笔记后图片会丢失;

只需要在普通笔记标题后添加“.md”后缀即可生成md笔记,删除后又可以退回普通笔记;

可以使用所有你能想到的用来编辑普通笔记的编辑器编辑Markdown笔记,包括百度编辑器,写字板和Word(你没有看错,能编辑Md的不只是Editor.md插件);

编辑Markdown时,Markdown文本是富文本(可以附带各种各样的格式)

……

不知道大家有没有对这些现象产生强烈的疑问?对我而言,这些疑问在一段时间里常常在我脑海种浮现。当我同时解压一个Md笔记与普通笔记做对比的时候,上面的现象都会得到了解释。

一篇Markdown笔记与一篇普通笔记所包含的文件是一样的,而找遍整个Markdown笔记压缩包都不会找到一个以.md为后缀的文件。只有一个名为index.html的文档,而这就是我们要找的Markdown文档。

这就是为知Markdown的真相:为知的Markdown笔记是Html文档格式的,为知的Markdown功能是在HTML上实现的!

当我们使用一个所见即所得HTML编辑器的时候,它的实现逻辑是这样的:

3a16180b6c6590d58fc06acc0aed44cd.png

编辑器作用于HTML文档的源码,然后HTML文档被渲染成网页返还编辑器显示,实现了所见即所得。

而一般的Markdown编辑器的实现逻辑是这样的:

9da8b046abb9397bc43cee44f44d2af7.png

编辑器作用于Markdown源码,并返还编辑器中显示。如果支持实时渲染,Markdown会转化成HTML语法,然后渲染成网页实时返还编辑器中显示。

为知的Markdown是建立在HTML基础上的,所以逻辑更加复杂:

d9efb0a1917199376b1dfaafd07a68d4.png

为知编辑器作用于HTML源码,HTML被渲染成记录着Markdown的网页,如果是编辑模式,这个写着Markdown的网页就直接在编辑器中显示,相当于HTML编辑器的逻辑。如果是阅读模式,网页上的Markdown被转化成HTML,然后HTML渲染成网页(最终结果)返还编辑器中显示。

看图的左侧,类似一个所见即所得HTML编辑器逻辑。看图的右侧,类似一个Markdown编辑器的渲染过程。所以为知的Markdown实现方法可以简单的总结为在一个所见即所得HTML编辑器上搭载了一个Markdown渲染工具。

下面是吐槽总结点评的时间:

我们知道,Markdown的目的是转化成HTML发布,而为知的Markdown却使用HTML记录,总给人一种本末倒置的感觉。原本的HTML渲染成Markdown,然后Markdown又被渲染成HTML,又给人太迂回的感觉,不对,是为知遵循否定之否定的必然规律实现了螺旋上升……Markdown本身是纯文本,而为知的Markdown文本是HTML渲染之后得到的,可以是富文本,所以使用为知自带编辑器经常会得到格式古怪的“Markdown源码”文本。一般的Markdown编辑器是针对纯文本的,所以富文本的为知Markdown文本中的图片会被冲掉。因为渲染了两次,所以经常会闪一下。因为Markdown文本是用HTML记录的,所以加个后缀就可以当作Markdown(其实内部没有进行两者之间的转化),所以为知的Markdown与普通笔记可以共用一个编辑器,所以所有可以用来编辑HTML的编辑器都可以用来编辑为知的Markdown文本。

这种Markdown实现方式,最直观的问题应该是效率问题。因为流程太长,而且需要渲染两次,打开Markdown笔记的速度必然会收到影响,本人的实际体验是打开一篇Markdown笔记一般都需要2s左右,中间会看到Markdown文本先被显示然后被替换。看到自己电脑渲染这么慢,我都替为知的服务器心疼。使用Editor.md插件的时候更是明显,写一篇稍微长一点的Markdown笔记就会变得十分慢,需要关闭标签重新打开,但是没过多久又会变卡。

长远的看,这种Markdown会被底层的HTML深深的束缚住,难以发展,比如想开发一款Markdown编辑器,那么这个编辑器首先是要基于HTML编辑器的,而为知自带的HTML编辑器都又很多问题,让人很怀疑为知开发这Markdown编辑器的能力。再比如想加入本地图片功能,在不改变现有HTML文件包结构的情况下很实现难。

当然,这种方式也不是一无是处,有一个非常大的好处就是可以让所有的笔记格式齐平,这对搜索、笔记整理以及文件安全是有很大帮助的,因为同时支持两种不同的格式会让搜索和笔记整理的工作量大增,所有的功能和规则都要开发两套,那工作量是翻倍的,而且会容易变得非常不稳定。这大概也是大象(印象笔记)一意孤行不采用Markdown的原因之一吧。

最后说一下为知独创的添加图片和表格方式,那是一种为知自己图方便的办法,让第一次渲染得到的图片和表格在第二次渲染中不被过滤直接输出。Markdown本身是兼容HTML标签的,但是为知这么一搞,变成了好像是HTML在兼容Markdown语法一样。而且这样让Markdown变成带图片的富文本,这样的Markdown是个非源码又非所见即所得的四不像。这可能体现了为知对Markdown的理解,但是这样做没有太大意义,真正使用Markdown写笔记的人是不会用这种方式的,因为为知不是Bear,目前还没有足够的用户粘性,让用户只用自带编辑器来书写Markdown,而且这种方法也与Editor.md插件不兼容呢。如果有为知官方人员阅读此文,请考虑放弃这种添加图片和表格的方式,探索更好的方式。

对为知Markdown的展望

虽然对为知的Markdown抱怨甚多,但还是展望一下为知Markdown的未来,希望为知能看到。

解决效率问题

说实在,这是本人目前面临最大的问题,而且也是最直观的问题,打开Markdown笔记会比普通笔记慢一拍,而且会闪(在移动端也是如此),插件编辑会卡顿。虽然这些问题都是为知Markdown机制决定的,Markdown笔记会比普通笔记有更多的步骤,但还是希望为知在这个问题上想想办法。重构Markdown的实现机制?还是更改处理的顺序,先区分Markdown笔记和普通笔记再进行渲染?

还有插件编辑Markdown一段时间后容易变慢,这个当然与个人机器性能有关,但是我打开Word写长文本一点问题都没有,反而用为知写Markdown觉得卡,这很尴尬。自从用了为知的Editor.md插件之后我就没有在使用其他Markdown编辑器了,最近用Markdown写长文本,响应慢的问题越来越严重。目前已经产生了放弃使用为知编辑笔记的想法了,以后可能只把为知做收集和整理,将笔记书写交给其他应用。如果为知有能力自己开发一款自带的Markdown编辑器的话,虽然不能从根本上解决问题,但是在响应速度上应该可以得到很大的改善,不过这需要提前对Markdown笔记和普通笔记进行区分就是了。

Markdown编辑器

虽然有Editor.md插件,但是一个自带的Markdown编辑器总是需要的,插件的功能再多,性能上总是受限的,而且使用插件编辑Markdown时笔记工具栏会消失,无法编辑标题,无法添加附件,无法添加标签等等。现在的Markdown编辑器发展太快,因为Markdown语法本身就限定了功能的范围,所以目前的Markdown编辑器的关注点大多在用户体验上。虽然拿一个专业编辑器来要求一个笔记软件是不公道的,笔记软件也很难达到那样的高度(Bear那样极度强化书写功能的怪物例外),但是一个专门的Markdown编辑器非常必须。Markdown只是书写语言,是为平台或编辑器服务的,不同于HTML,不是发布语言,所以不要奢望把Markdown完全交给外部编辑器,为知的Markdown编辑器应该实现下面几点功能:保证Markdown的纯文本特性。首先编辑器书写的Markdown文本应该以纯文本呈现,乱七八糟的格式太影响书写。其次是编辑器可以让从别处复制过来的富文本转化成Markdown语法的纯文本。如果不能重新搭建一个Markdown编辑器,起码在现有的HTML编辑器中加入一个纯文本模式的功能。

图片插入。前面说过图片插入的问题,HTML式的插入图片破坏了Markdown纯文本特性。那有没有方法,既能满足Markdown语法,又不破坏现有的HTML文件框架,甚至可能被外部纯文本编辑器编辑过后不掉图?我有个idea不知道可不可行,供参考。首先图片依然存放在\index_files\……路径下,编辑器中新增一个板块专门管理和查看\index_files\……下的图片(这里暂且将这个板块称为图床),然后图片Markdown语法使用参考式。每当在图床中添加图片,会在Markdown文档最后添加一个参考id,id为图片名字。用户想添加图片的时候,使用参考式图片语法![][id]即可插入图片。如果将图片直接拖拽到Markdown文档,会在图床和\index_files\……路径下添加图片,同时在Markdown文档中插入一个完整的参考式语法。图床最好会锁定\index_files\……下的图片,只有在图床中删除图片,才能让图片从\index_files\……中删除。如果想使用外部编辑器,只要先把需要用到的图片放到图床,然后调出外部编辑器,使用参考式语法就可以同样插入图片。另外还能让用户在图床中对图片进行放大查看、修改和替换。我觉得这是个难度少,但是受益巨大的做法,请为知认真考虑。

最好有语法高亮或语法识别。对于双栏实时预览,我觉得其实意义不大,那是给初学者用来过渡的,因为会造成信息冗余,占用笔记区空间,而且实时渲染也需要占用一定的资源。但是Markdown毕竟是源码输入,难免会打错语法,所以输入Md语法之后编辑器最好提供一个反馈,或是高亮,或是其他的样式改变。

编辑时空格可以被方便显示。空格是Markdown语法中很重要的语法元素,空格的数量不对就可能造成一些语法错误,但是空格不方便看,希望编辑时空格会被方便显示出来。有的编辑器将空格显示为灰色的点·。

目前的自带编辑器无法实现对大纲的预览,在阅读模式才可以看到大纲,如果愿意开发Markdown编辑器,希望可以加入大纲功能。如果为知笔记不希望在编辑器上着力太多,请优先实现第一第二点。

Markdown语法

为知其实已经支持挺多Markdown语法的,所以这里稍微提一些展望缩进式代码目前有bug,多行代码会变成一行,而且没有行号。

为知的Markdown表格不支持第一单元格为空。

围栏式代码目前只能用3个反引号包裹,希望可以用3个以上的反引号,这样就可以使用Markdown记录Markdown语法了(有点绕)。

MultiMarkdown支持修订语法(CriticMarkup),可以高亮文本,添加注释。有没有可能加入到为知助手中呢。

目前不少Markdown支持元数据,有点类似HTML的开头部分,可以添加标题,作者之类的信息,很实用。但是鉴于目前为知的Markdown机制,元数据好像只会添麻烦。但是这里说个题外话,目前的界面标题栏于工具栏共用一行,而笔记页标签又有题目,感觉有点信息冗余:

e28b71c21b0348f8a1a57df97ea99e95.png

多希望题目这一类的信息放到文档开头,打开向下箭头可以查看和修改更多信息,然后向下滚动的时候可以被隐藏,画了个示意图:

180f01bd5b6635b1d297a7185345a501.png

是时候让为知为Markdown也做点贡献了,希望为知可以发明个绘制简单的思维导图的语法,可以像绘制流程图一样,使用围栏式区块代码实现,代码用Markdown的列表或者标题就行。我觉得这样比使用开发插件或模板来的实在,更有用户粘性,可以源远流长,成为一大亮点。而且国外其实已经有软件实现了Markdown语法向思维导图的转化,只是没有将其设计成语法用于Markdown书写。

为知作为一款笔记软件,如果不把编辑作为重点的话,那么希望在阅读方面做一些优化,尤其是Markdown的渲染和阅读。比如对于单独成段的图片,可以渲染成区块,有的衍生语法就是这么设计的,还有如果图片比较大,阅读时支持点击放大查看。

开放API。为知笔记作为一款笔记软件,功能上不可能面面俱到。如果为知笔记的开发重点不在笔记编辑这一块的话,像大象一样开放API或许是最好的选择,毕竟只有Win端才支持插件和外置编辑器。

  • 0
    点赞
  • 2
    收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:游动-白 设计师:我叫白小胖 返回首页
评论
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值