Some code tools return "\r\n" on Windows.

[UnderCooled]

This is codespell diagnostic message:

These "^M" are "\r" characters, but not all code tools will use "\r\n" on Windows, maybe user should define a parse function to filter out these "^M"?

Tools without json output may have this issue on Windows, so guard can also fix it in diag_fmt function.

guard.nvim/lua/guard/lint.lua

Line 95 in 4645785

message = message or '',

message = message and message:gsub('\r', '') or ''

or with an OS check if?

[xiaoshihou514]

Seems like a CRLF issue, I wonder if nvim_replace_termcode would fix it

[UnderCooled]

I think Python-based tools have this problem.

Reference: python/cpython#57328

我接下来用中文表达，英文不是太好。现代三大系统应该就 Windows 还在用 "\r" 了，现在的代码把工具输出的信息按 "\n" 分割后解析成行号列号消息等等，那么这个 "\r" 出现在消息之中是不是应该除了某些工具为了兼容 Windows 的命令行窗口之外没有什么用处。但可能某个 linter 检查代码时，发现代码中有触发什么 "\r" 规则，而返回了一行诊断信息中包含了 "\r" 的提示信息（不过这样的信息是不是也应该是已经转义的 \\r 呢），那么只删掉消息中处于最末端的 "\r" 应该不会引发什么问题吧。

[xiaoshihou514]

I was hoping there is a generic function that would handle these platform dependent quirks, which would also fix other potential CRLF related issues 🤔 But if there isn't one maybe we could apply the monkey patch you described 👍

[xiaoshihou514]

Ah, vim.split takes regexes, so vim.split("\r?\n") would solve this