能否补充一些简写缩写方便输入

[kaikaiiiiiii]

比如，在已知 componentDiagram 的情况下，

Interface 可以简写为 ()
component 却不能简单简写为 []

比如
component comp4 [
This component has
long description
]
如果简写为
[] comp4 [
This component has
long description
]
字符串解析其实是没疑问的，但实际上会报错。而改写为
[comp4
This component has
long description
]
则会把 'comp4' 也作为内容渲染出来。显然是不对的。

同样比如在已知 sequenceDiagram 的情况下

activate Pintora 和 deactivate Pintora
是否能使用相同的 !Pintora 切换，或者至少允许 !Pintora 和 !!Pintora 作为简写

@note left of ==> @nl 或者 @< 或者 @====< （等号任意多）
@note right of ==> @nr 或者 @> 或者 @====>
@end_note.==> @@

其它还有挺多可以简写的

[hikerpig]

的确是可以有简写，不过每增加一个这不是都需要开发量么（包括 parser 实现和 VSCode 的语法高亮规则...），可以慢慢考虑优化。

1. componentDiagram 我基本上是看着 PlantUML 的文档页写的，有一些可能还没支持全。这个 [] 感觉可行 。
2. 用 ! 做toggle 的语法我感觉不太合适，太依赖上下文了，用 + 或者 - 的话可能可以考虑下（在 message 里已经支持了，可以保持一致）。
3. @note 相关的我好好想想（主要是没得抄 = =），简写太多了其实记忆起来也挺难受的... 造得不好还可能在不同图表间支持不一致造成疑惑。

开老师有什么新想法的话随时可以补充哈，我多收集收集。

[kaikaiiiiiii]

我不太清楚 parser 的实现，自己实践中只做过 json 的解析。

不过大致考虑了下，这些前置控制符其实是等位的，理论上，只需要你的控制命令的集合里，不存在 字符串 A 是 字符串 B 的真左子串的情况，就应该不会出现解析上的混淆。

至于用户对语法一致性的理解。……我之所以建议 @====< 也是有这方面的考虑的。

@====<
左 note 内容
@====@

这种形式，即使不转化成图形，语义解读应该也不是太大问题。

[hikerpig]

先考虑一下 note 这个语义是不是足够特殊和常用到需要一个@@ 这么特殊的符号来识别……
然后 er 图现在还是不支持 note 的？感觉后面 note 可以统筹一下给所有图表都加上（同时不侵占原先的语法，以及提供双引号包裹名字的语法来避免和名字之类的混淆）。到时候再考虑统一的简写。

[kaikaiiiiiii]

agree