希望支持 kmarkdown 的构造和解析

[MeetWq]

@abrahum 的 kook 和 walle-k 中实现了类似的功能：

https://github.com/abrahum/kook/blob/master/src/kmarkdown/mod.rs
https://github.com/abrahum/kook/blob/master/src/kmarkdown/parse.rs
https://github.com/onebot-walle/walle-k/blob/main/src/parse/message.rs

[Tian-que]

这周末看看能不能超一个

[ssttkkl]

其实我不太理解为什么需要构造和解析kmd，手写有什么局限性或者说构造和解析有什么优势吗（）

[MeetWq]

其实我不太理解为什么需要构造和解析kmd，手写有什么局限性或者说构造和解析有什么优势吗（）

类似于为什么要用 MessageSegment 代替 CQ码
手写发送的时候还好，解析的时候就麻烦了，比如我现在有个需求是从 kmd 中拿到被 mention 的 id

[ssttkkl]

我觉得比较好的方案是把kmd相关的功能单独做成一个库，然后由插件开发者手动调用。
一方面我理解kmd和cq码不一样，大部分场景都不需要做解析，没必要引入额外的性能开销，另一方面可以直接用pyo3之类的方案把上面现成的rust库粘上

看看@Tian-que 怎么说

[ssttkkl]

其实需要mention的id的话可以在事件的extra属性拿到

nonebot-adapter-kaiheila/nonebot/adapters/kaiheila/event.py

Line 71 in 7a495b3

mention: Optional[List[str]] = Field(None)

[kexue-z]

KMD 我搬了这个来用 https://github.com/kexue-z/KaiheilaCardBuilder

自己用了一些写的 https://github.com/kexue-z/Dao-bot/blob/master/plugins/mc/kook/utils.py

效果-->

[Tian-que]

其实我不太理解为什么需要构造和解析kmd，手写有什么局限性或者说构造和解析有什么优势吗（）

类似于为什么要用 MessageSegment 代替 CQ码 手写发送的时候还好，解析的时候就麻烦了，比如我现在有个需求是从 kmd 中拿到被 mention 的 id

从复用角度来看，就像@ssttkkl 说的那样， 这部分可以单独抽出来作为一个功能性组件，@kexue-z搞了一个Python实现的KaiheilaCardBuilder，可以试一下

[ssttkkl]

https://gist.github.com/RF-Tar-Railt/d8d48812303a477a09868dc1bd08a0d9