是否将此更改为Vim'；sed的语法着色文件是否正常或中断？ 总结 我不是在问你对提议的改变是好的、坏的、惊人的还是什么的看法 我只是想请你帮我回答这个问题：我建议对注释的语法着色进行的更改是否会破坏其他内容（关键字、字符串、语法错误等）的语法着色 上面的问题不是基于意见的，因为我的改变要么破坏了什么，要么没有。就这样 原始问题

我在Vim的GitHub页面上创建了，以建议对

Vim/runtime/syntax/sed.Vim

进行更改，但它没有受到太多关注，因此我正在考虑为更改创建PR

事实上，我创造了一个问题，而不是公关，因为我不完全相信这一变化不会造成破坏，所以这个问题

问题在于第20行：

syn match sedComment    "^\s*#.*$"

因此，只有“整行”注释被着色为注释。在命令后面使用尾随注释（例如，GNU sed允许），会刺激一些红色背景着色（因为我猜，语法着色逻辑认为这是一个错误）

我认为放宽注释的定义以允许GNU-sed风格的注释是合理的，原因很简单，该规则限制较少

在这方面，我注意到将该行更改为

syn match sedComment    "\s*#.*$"

i、 e.仅仅移除锚定

^

，似乎就足够了。我还试着通过在sed脚本中放置一些

#

搜索和替换字符串来测试它，结果似乎不错

但是，我对Vim语法着色文件没有信心，所以我希望确保在编辑它时，正则表达式不会导致误报

为了说明为什么我对它没有信心，请使用这一行

sed

脚本

s/aaa/bbb/#ccc

此处的

#

不作为注释着色，而

ccc

的背景为红色（如错误？），而只是添加一个空格，给出正确的颜色：

s/aaa/bbb/ #ccc

因此，我认为我的编辑工作（或似乎工作）是因为几个语法着色指令之间的优先规则（关于这个使用

s/aaa/bbb/#ccc

的具体示例，我认为

命令的结束分隔符后面的

在语言中有意义，但我不知道；GNU-Sed

man

页面没有说明任何内容）

编辑 注释中建议的另一个示例如下，其语法着色为而不是被提议的更改破坏

s/#if !defined(\([^)]*)/#ifndef \1/ # with or without this comment is fine

我的研究 我终于找到了一些时间学习

：he410

，现在我有了答案

从那里我读到了

因为我要更改的行使用语法2

• 第1点不相关
• 第3点。是相关的，因为通常情况下，

  syn匹配

  和

  syn区域

  匹配之间可能存在重叠

（顺便说一句，我验证了

syn region

使用了一个惰性正则表达式，可能是

\\\\.{-}

在后面查看一些示例，以匹配

start

和

end

regexp模式之间的内容。）

然后从

：h:syn优先级

答案 因此，改变

syn match sedComment    "^\s*#.*$"

到

不应引入任何语法错误，原因是如果与上述正则表达式匹配的文本实际上不是注释（例如，命令

s/#/hash/

），则必须在其前面加上一些非注释语法，这些语法将由其他

syn match

/

syn region

组匹配。由于此匹配在组

sedcoment

开始匹配之前开始，因此前者优先于后者

总之，除非sed.vim已经破坏了某些东西，否则建议的更改不会导致错误的语法着色

s/x/y/a

进一步观察 实际上，

sed.vim

中已经有错误，我建议的编辑并不能解决它（我应该编辑

sed.vim

中的其他行来修复它，但我现在有点懒）

例如，在下一行中，这是非法的，因为

a

不是有效的标志，

a

没有得到

错误

的颜色

s/x/y/a

我建议的编辑无法解决此错误

出于同样的原因，由于其他一些语法规则正在替换命令中的第三个分隔符后插入1个字符，因此以下命令中的GNU-

sed

-valid注释的颜色不正确

s/x/y/#hello
#     │└───┴─── colored as Error
#     └─ not colored

即使对于不允许尾随注释的旧版本

sed

，着色也是错误的，因为

Error

着色也应该包括

#

。 我建议的编辑也不能解决这个错误

再观察一次 我建议的更改会导致单字母命令在后面加注释时突出显示为

Error

p # this is a comment
│ └─────────────────┴─── colored as Comment (ok)
└────── colored as Error (bad)

同样，这并不是一个恶化，因为当前的

sed.vim

几乎把上面的整行都涂成了

错误

我的研究 我终于找到了一些时间学习

：he410

，现在我有了答案

从那里我读到了

因为我要更改的行使用语法2

• 第1点不相关
• 第3点。是相关的，因为通常情况下，

  syn匹配

  和

  syn区域

  匹配之间可能存在重叠

（顺便说一句，我验证了

syn region

使用了一个惰性正则表达式，可能是

\\\\.{-}

在后面查看一些示例，以匹配

start

和

end

regexp模式之间的内容。）

然后从

：h:syn优先级

答案 因此，改变

syn match sedComment    "^\s*#.*$"

到

不应引入任何语法错误，原因是如果

p # this is a comment
│ └─────────────────┴─── colored as Comment (ok)
└────── colored as Error (bad)