这个提示好像有点怪怪的，应该和语法文件的实现有关

[openai0229]

这里看到写了一个简单的查询语句，但是我没有写分号，这一块就已经开始提示create这个关键字了，这个应该和语法文件的规则有关系吧，语法文件中似乎并没有强制需要分号作为语句的结束符，所以他就识别到新的sql开始去了，所以就会有这个关键字了对吗？

这个我也不是很清楚是不是一个bug，希望可以讨论一下

[liuxy0551]

dt-sql-parser 将语句识别为一个 singleStatement 也就是一条完整语句时，会自动断句，并不强制要求写分号。但在部分场景中，会依赖分号进行切分，比如正在进行的两个 PR：

• feat: complete after error syntax dt-sql-parser#334
• feat: support semantic context of isNewStatement dt-sql-parser#361

[openai0229]

好的，谢谢，我去看看

[openai0229]

这个情况应该怎么优化呢，其实我这里明确有一个点了，应该不是新的语句的开始了, 这个会不会和那个PREFERRED_RULES有关系？其实我也不太懂PREFERRED_RULES的作用，好像加了他之后，收集到的token似乎在某些场景下会准确一下

[JackWang032]

这个情况应该怎么优化呢，其实我这里明确有一个点了，应该不是新的语句的开始了, 这个会不会和那个PREFERRED_RULES有关系？其实我也不太懂PREFERRED_RULES的作用，好像加了他之后，收集到的token似乎在某些场景下会准确一下

preferredRules 主要是用来收集光标所处于哪个上下文的，如添加了Rule_createTableName, 当正在输入建表表名时，则会在收集结果中candidates.rules存在该规则。
输入点后会出现很多无关的关键字，是因为该处的lexer为 id, 而id由用户自定义输入Identifier与nonReserved非保留关键字组成，所以提示的无关关键字都是由于匹配了非保留关键字造成的，这与所有语言的语法文件有关，我们有计划在明年剔除这些多余关键字。

如果要临时解决，可以尝试根据输入上下文自行剔除，可以参考c3中如何处理上下文信息的 antlr4-c3

[openai0229]

其实我现在的做法遇到需要用户自定义的id规则就全部直接不返回任何提示

[openai0229]

这个情况应该怎么优化呢，其实我这里明确有一个点了，应该不是新的语句的开始了, 这个会不会和那个PREFERRED_RULES有关系？其实我也不太懂PREFERRED_RULES的作用，好像加了他之后，收集到的token似乎在某些场景下会准确一下

其实这里我想到一个做法就是，就是判断当前光标所处的token是不是"." , 如果是的话，就不返回关键字的候选提示，应该没有关键字通过"."相连的情况

[JackWang032]

后续预期支持严格模式，必须以分号结尾作为语句结束标记