Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(render): handle large messages when calculating line width #283

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

flrgh
Copy link

@flrgh flrgh commented Jun 20, 2024

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().

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:

  1. 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
  2. I updated the calculation to use vim.api.nvim_strwidth() when available (see fix: improve string width calculation #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:

```
[...]/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()`.

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:

  1. 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
  2. I updated the calculation to use `vim.api.nvim_strwidth()` when
     available (see rcarriga#247).
@flrgh flrgh force-pushed the fix/message-width branch from b721926 to 7b4075b Compare June 20, 2024 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant