-
Notifications
You must be signed in to change notification settings - Fork 55
refactor: re-add smart component truncation #132
Conversation
expr = ffi.cast(char8_str_t, expr) | ||
|
||
ffi.C.build_stl_str_hl( | ||
ffi.C.curwin, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you're expanding for winid you need to pass win_T pointer for window of that winid else you'll get wrong results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you're expanding for winid you need to pass win_T pointer for window of that winid else you'll get wrong results.
How would I go about doing that? Sorry, I'm really not familiar with Neovim's codebase
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figured it out. Though it'd be nice if I could reuse the window value to access its w_width
member to avoid calling api.nvim_win_get_width()
, but trying to do that makes Lua complain about the unknown size of the win_T
struct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to put struct window_S
definition in cdef
if you want to access w_width
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to put
struct window_S
definition incdef
if you want to accessw_width
.
Yeah, I'm aware of that. But honestly that seems like more trouble than it's worth
lua/feline/statusline_ffi.lua
Outdated
-- Expand statusline expression, returns a Lua string containing plaintext with only the characters | ||
-- that'll be displayed in the statusline | ||
function M.expand_statusline_expr(expr, winid) | ||
local stlbuf = char8_buf_t(256) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can create this buffer at module level and keep reusing it for better performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can create this buffer at module level and keep reusing it for better performance.
But then wouldn't the data be overriden everytime the function is used?
EDIT: Nvm, since it's copied into a Lua string using ffi.string
anyway, that shouldn't happen
This seems to still have one issue, the inactive windows are not automatically truncated when a window is resized. This is more of a (Neo)Vim limitation since it doesn't have a |
It seems that using |
Instead of setting local statusline option for inactive windows you can use global option and draw inactive or inactive status based on which window you're in . I do that in lualine just set an entry point in global option then draw different things from that single entry point. That way inactive statuslines also gets dynamically updated just like active statusline. Or instead of triggering updates based on events you can update the inactive statuslines based on a timmer. |
I had no idea g.actual_curwin even existed, that can actually make it possible to not pass winid to every function |
Read |
I did but I missed that part entirely somehow |
81da3ef
to
56eb9dd
Compare
After rebasing it against the latest develop after #135. This seems to work really well, so I'm going to merge this now |
Now fully supports VIm statusline expressions. Thanks to @shadmansaleh for assisting with the FFI code required for that. This should work perfectly fine. The only issue is that it causes a 53% performance downgrade, which is a pretty big issue. The downgrade is not really noticable to me but not sure about others. Not a fan of it using FFI to access Neovim's internals either, mostly because I don't have much knowledge about Neovim internals so it'd be a pain to troubleshoot a problem if the source of the problem is the FFI code.