@renmu123 我主要是在 Markdown 和 HTML 之间取得平衡，的确很难把握。但我现在的构想已经做到了：写简单文档时，真的就像 Markdown 一样简单，其规则甚至比 Markdown 还简单（但不如 Markdown 美观）；随着需求的增加，慢慢去了解一些更复杂的功能，发现还是可以做到。

@humpy 淘气，你说的这个名字不好听。

以前在京东买书的时候，喜欢在一家店把所要买的书凑齐。在当当购买，你根本看不到这家商铺还有卖其他什么商品，导致不得不在多家购买。现在每本书打电话过来，都说我只在人家这里买了一本。所以如果我要吐槽，似乎只能吐槽当当网上的不良店铺。

但实际情况是，我就这么随机买 5 本书，都点最前面当当推荐的链接购买，有 4 本都是旧书，还在同一个城市。所以我分析，这个操作有很大可能是当当自己弄的马甲来卖旧书的，不然其平台的店铺这么嚣张，当当不可能不知道，甚至会配合商家把店铺的所有信息抹去，只剩下店铺首页一个带有警告性质的图片公告。

@gilgameshcc 你说的这两个似乎都有共同的卖点——类似于 MediaWiki 内部链接的功能。有时间我也多了解一下他们。

另外我原来也是想针对 Markdown 修修补补，但后来发现无法满足我的主要要求，干脆就来个系统性更改。

@flyhelan 谢谢，我自己的精力就只能把规范写出来，编程实现我没功夫做，到时候就在 Github 上把规范公开发布出来。不过感觉大家都不太在意这个，或许这种设计不太吸引人，收到的反馈太少了。

@krjt 粗看了一下 Pollen，感觉在标记语法上跟我设计的稍微有点像，即都是用标记加括号对界定的内容。

不过它所有的标记都用英文单词，还用一个奇怪的 ◊ 符号开头，这点我不喜欢。我觉得轻量级标记语言就应该有点折中，常用的标记用标点符号来标记会更好点。其他自定义的 class 、id 、甚至和 HTML 对应的标记名称允许使用多种语言会更好（如中文用户不用“abbr”，而直接用“缩写”）。

另外看介绍它用的标记似乎要超越 HTML，我觉得不必要，对标 HTML 有利于内容的发布。

——我没有仔细看，或许我评价的不对。

@JackalZhao 说实在的，这个格式主要不是面向程序员设计的。我是一个不愿意学也不愿意用 LaTeX 的人。

@flyhelan 我用 Markdown 写的这个帖子。你说用数字序号介绍功能，这正是 Markdown 不容易做到的。因为许多项的功能需要多个段落介绍，而 Markdown 很难做到一个列表项中有多个段落，且保持列表项编号连续，所以将就着就用无符号列表了。反而，用我设计这个格式，就容易做到了，如：

#[[
列表项 1 的段落 1

段落 2
]]
# 列表项 2

(上面井号表示有序列表项，没有用 Markdown 中的数字法，因为需要用两个井号 ## 表示次级列表)

这里只是很简略随意写了部分功能，至于解决了哪些痛点，如何解决，我正在用一个长长的文档在详细讨论——这个东西写起来很折磨人。这里简要说一下解决了哪些痛点吧：

1. 常见的轻量级标记语言难以写作学术文档的问题。学术文档有大量的图、表、公式、参考文献，需要对他们进行自动编号、引用、生成索引等，常见的轻量级标记语言很难做到，另外 Markdown 甚至都没有上下标标记，更没有针对变量元素 var 的标记。
2. 大型文档的写作与组织问题。这个格式要尽量做到让用户无心智负担地写大型文档，即将大型文档分割成多个单元，每个单元就像写一篇博客一样，在写作时除了交叉引用，不用考虑该单元在整体文档中的位置，可以很容易地将他们组织在一起形成大型文档。这些主要是通过规定如何更具上下文灵活判定各个标题的大纲级别来实现的。以及设计在文本中包含参考文献等编号项，而不是在文末给定编号项列表。
3. 语法的一致性问题。其他各种标记语言对不同的元素有多种语法，而本格式的语法基本上可归纳为“标记符号 + 以方括号界定的内容或属性序列”。由于大多数情况下都遵循相同的标记规则，因此学习起来负担相对较小。
4. 重新设计**本人认为**最合理的标记元素。如在行内元素中，分别用 +、-、*、/ 表示插入、删除、着重强调和强调，这些都非常便于联想记忆。用 ^、_ 表示上下标，这是为了和 LaTeX 保持一致。用 = 表示各级标题，这是我觉得等号比较容易输入，而井号要用来表示编号列表、ID 等。
5. 功能扩展问题。Markdown 支持的元素类型有限，而该格式则更多，该格式还能较容易地为元素添加类、ID，以及其他自定义属性，甚至该格式还能添加与 HTML 各种语义化标记对应的 figure 、figcaption 、abbr 、address 、kbd 、time 等（有时候是很有必要使用这些标记的）。在某种程度上，该格式与 HTML5 的常用语义化排版标记是等价的。
6. 块级元素的嵌套问题。Markdown 中很难做到各种块级元素正确嵌套，如前面提到的列表项中很难嵌套多个段落，以及单个表格单元中有多个段落，甚至表格单元中嵌套表格。本格式由于使用了方括号对作为内容或属性的定界符，因此很容于做到块级元素嵌套。另外针对各种块级元素嵌套段落元素，还做出了各种特殊的简化规定。
7. 中文支持问题。该格式默认段落内换行符就是 <br>。为了解决在中文输入法下输入标记符号麻烦的问题，规定了可以使用英文标点符号，而在解析时可将其转换为中文标点符号。如用 ... 表示半个省略号 …，用 --- 表示半个破折号 —，这里比较麻烦的是英文中没有顿号，所以目前暂时用两个逗号 ,, 表示顿号。

主要特点是：

1. 元素的标记方法和以往常见方法又很多不同（不一定不原来更好，但只有这种标记方法才能满足一些特殊需求，如添加类、ID 以及其他属性）。
2. 具有几乎与 HTML5 相匹配的文档描述能力。
3. 更适用于科学技术报告、学术论文、书籍的书写，具有图、表、公式等的自动编号、交叉引用和索引功能。
4. 具有灵活的文档组织能力。
5. 尽可能保持语法的一致性和对称性。
6. 当使用相对高级的功能时，所生成 HTML 文本的正确显示需要依赖特定的层叠样式表(CSS)甚至 JavaScript 代码。

@cmdOptionKana 你仔细比较一下我介绍的和 reStructuredText 的区别，我觉得差别很大很大的。

@SilentDepth @qqqqqcy 谢谢！

原来是考虑把自己用 JavaScript 生成的模型对象持久化，不过还是得考虑一下是否需要如此。

另外，本来也不打算用 jQuery，而是想着针对我的模型结构自定义编写一个可视化模块。

sudo snap install go

你会发现这样安装的 Go 是 1.14.2 版本的。

非前端，借此话题，针对目前手头上的一个项目，大家看看我这种技术选择对不对：

项目需要从后端传递过来一个类似 GeoJSON 或 TopoJSON 格式（其实是完全自定义的格式）的 JSON 文本（很大），在浏览器端生成对应的 JS 对象实例，并据此使用 SVG 技术进行类似地图一样的可视化显示。由于是监控类项目，要借助 WebSocket 保持长连接，该对象实例不能在网页渲染后销毁，而是一直存在，并且根据后续传来的 JSON 文本对其进行更新。如果用 VUE/React 类技术，则浏览器端就会长久有以下三层了：

JS 模型对象 ⇔ 虚拟 DOM ⇔ 真实 DOM

但由于 JS 模型对象的格式是固定的，了解其中各个元素应该对应的 SVG 元素（可建立关联），且从服务器端传来新数据时必须要比较新数据和已有的 JS 模型对象的区别，因此觉得不用虚拟 DOM 会更好。即直接 DIFF 新旧 JS 模型对象，直接根据 JS 模型对象的更新来更新真实的 DOM 。这样省去了虚拟 DOM 层，省去了对虚拟 DOM 的 DIFF，或许能使性能大大增加。

或许对于我这种目标纯粹的单页面应用情况，会经常遇到，如 Google Docs 。不知道我这种不使用 VUE/REACT 类框架的技术选型对不对？

11 天后上车，谢谢！

同样是 17 年的小米笔记本 Pro，顶配，同样是经常睡死，发现这个问题已经过了保修期了，一直凑合。另外，同样经常有异响（关机插上电源也有）；还有风扇动辄就使劲转动，声音很大。真的是把人坑死了。

寒假期间睡死现象特别频繁，也没法出门换主板，最后在 Windows 的设置中把睡眠改为休眠，即要么关机，要么睡眠，从不休眠，一直插着电，半个月来没有出现睡死问题。供楼主参考。

PS：刚刚又买了个 Thinkpad P53，美行，感觉确实比小米本强太多了，当然，价格也在那里放着呢。

电梯质量好，电梯多，选高点的楼层还好；如果电梯质量差，或天天好多人挤电梯，还是低点好，前提是光线不被遮挡，不要临着大马路。

还有什么可说的，要么不用，要么： http://vip.wps.cn/

竟然还有人在这里说破解的，有本事在这里上个教程。

@Hzzone 是的, 发现在 Macbook 下 Linux 系统的触摸板很不好用. 至于软件, 只能说, 商业支持 macOS 的软件更多, 其他见仁见智.

还有很重要的一点，是任务栏，我总觉得点任务栏已打开任务名切换任务，是最直观的方法，而这个系统完全和我的需求一样。而 macOS 下对于 dock 栏，我始终纠结是一直显示，还是自动隐藏。