fix: don't blow up when nvim_buf_get_lines() returns Blobs

[wincent]

Some LSP servers may return binary garbage and nvim_buf_get_lines() will return a Blob instead of a String in those cases.

I added some print(vim.inspect()) debugging in
entry.get_documentation() to prove that by the time the text passes through there, it's already garbage.

Here's an excerpt from a sample line returned by nvim_buf_get_lines(), as rendered by vim.inspect():

default\0\0\0!      vim.opt.background = 'dark'\0\0\0000

(etc)

Now, this looks like an LSP bug to me, but I think we shouldn't allow buggy LSP output to crash nvim-cmp. "Be conservative in what you send, be liberal in what you accept" and all that.

So, degrade by coercing any Blob we see into a String before passing it to strdisplaywidth().

Closes: #820

[hrsh7th]

Could you explain why and when nvim_buf_get_lines returns Blob instead of string...?

IMO, neovim's docs does not describe this behavior.

[wincent]

Could you explain why and when nvim_buf_get_lines returns Blob instead of string...?

IMO, neovim's docs does not describe this behavior.

Sadly, I have no idea why. I just know that it happens. I suspect that a buggy language server (in this case, lua-language-server) is somehow producing the right kind of binary garbage — likely an invalid string encoding — to cause Neovim to encode it as a Blob. But I believe it's not limited to lua-language-server, based on the comments on #820, which mention this happening in various scenarios.

Whatever the bug is, I'm seeing it when nvim-cmp shows the hover documentation for Enum types; note the artifacts in the text:

For non-Enum types, it works fine:

[hrsh7th]

thank you.