Some misbehaving plugin code was sending very large messages to vim.notify(), which would trigger an exception when calculating the max line width for rendering:
[...]/notify/render/default.lua:6: too many results to unpack
To fix this, I updated the implementation to calculate the max line width in-place. This ultimately ends up being much more efficient because it is not creating a new table with vim.tbl_map().
In the large input benchmarks, the new function is ~2x faster. For small inputs (which are probably most common for vim.notify()), the speedup is even larger at 3-4x.
Other changes:
I noticed the same snippet appeared in multiple render modules, so I factored it out into notify.util.max_line_width() and added a unit test
I updated the calculation to use vim.api.nvim_strwidth() when available (see #247).
Some misbehaving plugin code was sending very large messages to
vim.notify(), which would trigger an exception when calculating the max line width for rendering:To fix this, I updated the implementation to calculate the max line width in-place. This ultimately ends up being much more efficient because it is not creating a new table with
vim.tbl_map().Here's some benchmark data: https://gist.github.com/flrgh/349aecd8ca35d20cf0526ec8b218657c
In the large input benchmarks, the new function is ~2x faster. For small inputs (which are probably most common for
vim.notify()), the speedup is even larger at 3-4x.Other changes:
notify.util.max_line_width()and added a unit testvim.api.nvim_strwidth()when available (see #247).