Vsnips
Vsnips copied to clipboard
corvofeng
讨论一下 ultisnips parser 和 extends 功能
目前的 snippet parse 基于正则 global search，实现 ultisnips 的一些语法解析稍微有点麻烦。比较容易的解析思路是：
- 先基于行查找，可以处理
extends/priority等其他关键词 - 碰上行首
snippet， 开始进入 “snippet 文本解析”状态 - 碰上行首
endsnippet，结束 “snippet 解析”状态，将读取到的完整 snippet 文本放入更细的 snippet body 解析函数中
不知道之后你有没有实现的思路，我在这里继续自荐一下 @unisnips/ultisnips ，基本按照 UltiSnips 用 ts 重写了一遍，基础 parsing 部分不会有什么分歧，可以去 demo 站试一下解析结果。然后 Vsnips 内相关的模板函数改写是在此之后的过程，不会受到影响。
这个是我目前在用的本地分支，包括两个新的 commit。
- parse 部分替换使用
@unisnips/ultisnips进行，同时修复了之前parse.spec.ts里一个解析结果的错误 - 添加 extends 功能的支持
extends 功能
关于 extends 功能，也是一个想要探讨的点。
我目前在的实现方式是在 SnippetManager 里记录好继承关系，然后 getSnippets 的时候再不断向上查询和添加。这样主要是考虑到之后会在用户改变 .snippets 文件的时候重新解析并更新对应 language 的 Snippet。
假如继承链为 'a -> b -> c' ，箭头方向表示 b 继承 a 。那么在 a 语言文件有更新的时候，只需要更新 a 的记录，b 和 c 的记录不需要改变。
关于正则解析的问题:
你所说的状态机解析方式, 我在一开始设计Vsnips时就考虑过这个问题, 其实正则也是一种状态机模型. 按照当前snippet的语法来说, 正则完全够用了. 而且不止在解析时使用了, 在替换函数时也用了. 项目如果分层使用正则, 阅读起来感觉也是ok的. 我个人考虑没必要一定换成函数写状态机去解析.
看到你改了VISUAL的那个测试用例, 请问是有什么和预期不一致的行为吗?
关于extend的功能:
这个功能应该是比较重要且紧急的功能了, 这部分代码你怎么改都可以, 你本地测试了. 我再检查一下代码, 再测试一下功能就好了.
另外看到你说要检查语言更新时的策略, 动态的监听snip文件, 我之前也考虑过, 这个功能比较重要吧, 但是感觉不怎么紧急(因为我们一般不会一直去修改snip, 除非调试), 而且这个功能实现起来容易有bug(snipmanager的出现可能会好一点), 我就一直没有考虑这个功能, 如果你有兴趣, 可以考虑慢慢实现.
既然说道到检查snip文件, 你是否有考虑过当运行网页版VSCode时的可能会遇到的问题, 网页运行中就没有文件系统可以用了, 该怎么给用户提供服务呢. 另外, 老哥你有兴趣建立一个snip的分享网站, 如果有snip对应的网站, 用户可以登录之后整理自己的snip, 之后即使在网页版的VSCode中可能也可以直接使用了.
那个 VISUAL 的测试用例，snippet body 有两个 tabstop 都是 VISUAL，然后原先的解析只出来了第一个，第二个就只有 $2 了，应该是不太对吧
Web 版我倒是没有考虑过，但是应该也不难，因为我觉着
fs模块肯定是要适配一下的，对多数插件应该都没有影响。
我们用的fs模块是node的fs模块, 在浏览器中是不能用的吧
Web 版我倒是没有考虑过，但是应该也不难，因为我觉着
fs模块肯定是要适配一下的，对多数插件应该都没有影响。我们用的fs模块是node的fs模块, 在浏览器中是不能用的吧
可以的，web vscode 这里重新实现一个 runtime 就行，fs 的接口也就那么些，实际的持久化可能是 indexedDb 之类的。
只有$2是因为第二个VISUAL里面是空的哈, 留不留VISUAL都是可以的.
如果我漏了啥纠正一下哈，但是 VISUAL 不是要替换成 $TM_SELECTED_TEXT 的么？
哦待会，其实这里还是不太对，应该得替换成 $TM_SELECTED_TEXT 吧...
