Closed cfbender closed 2 years ago
That syntax is potentially able to be interpreted as a statusline format string and vim would try to execute whatever is inside %{ }
as a vim expression. This is a problem if you had any provider returning the content of the current line. To prevent it, you need to make the output of such provider safe by substituting %
with %%
.
You should isolate the component that is responsible for displaying buffer content in the statusline and then protect the returned string by escaping %
. If it's something you read from the cookbook (I'm thinking navic component...) I'll update it.
Thank you for the quick response! it seems to be an issue with the AstroNvim heirline config then. I can try to track down the issue and open a PR/issue there
Glad to help, also thanks for bringing to my attention that AstroNVim uses heirline ;)
No problem! I think I narrowed it down to this provider, though I can't figure out why.
I think I will just open an issue there, and disable it locally for myself for now. Thanks again!
--- { provider = d.name }, -- add symbol name
+++ { provider = string.gsub(d.name, "%%", "%%%%")
something like this should fix it, it probably happens because %{}
is part of the symbol name returned by aerial
Thanks so much for looking at this @rebelot ! I will test out the change you have shared !
Yeah AstroNvim has been getting ready to migrate to using Heirline as the statusline. It will be in the stable release we are making on Friday for AstroNvim v2.0. Great work on this plugin it is super great and very fast and has allowed us to build a great API for letting users easily customize the statusline in Heirline quite nicely. If you are curious, here are our new docs for customizing the statusline in AstroNvim with heirline and our status module: https://astronvim.github.io/nightly/Recipes/status
great project! keep an eye on the cookbook for updates ;)
@mehalter You might want to check out updates on navic component for multi-window support and better logic for clickable elements (does not pollute global namespace with redundant functions) Converting it to work with aerial should be straightforward.
Thanks for the recommendation @rebelot ! Definitely super interested in improving the clickable implementation. I'll check out their implementation to help improve ours. I do want to continue using Aerial as the location engine mainly because it supports getting the location from more sources from just the LSP like if I just have treesitter running for example I can still get breadcrumbs for that. Also we are using Aerial already for having a symbol browser so not needing to rely on another plugin to get location when we have another plugin already calculating symbols as well. Hopefully that explanation is clear 😂 but will definitely check out the navic codebase to see how they are building the clickable elements
Checked out the code in the codebook and it looks great! Thanks so much for this, will definitely update our component in AstroNvim with this implementation!
Environment
On neovim 0.8 and latest heirline
When looking at at file that contains some elixir map in a match for a function declaration:
I get an error:
This also happens with something like
where I get:
and when I hammer it enough it comes out as this:
(excuse the screenshot, it's all I could grab of the issue
I originally thought this was an elixir-ls problem - but now it seems with that error that it stems from the
_eval
call from this plugin. I am still not sure it's not which-key? but it seems like the trace just shows that as being it's re-render function.Thanks so much for the help!