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.

Sign up for GitHub

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

Jump to bottom

feat: refresh lualine based on timer + winbar support. #736

Merged
merged 23 commits into from
Jul 22, 2022
Merged

feat: refresh lualine based on timer + winbar support. #736

merged 23 commits into from
Jul 22, 2022

Conversation

shadmansaleh
Copy link
Member

@shadmansaleh shadmansaleh commented Jul 12, 2022 •
edited
Loading

What it is

With this lualine will control it's own refresh instead of relying on nvim.

If we refresh this way we should be able to change out the statusline, winbar, tabline options and still be running . We should be able to address #689 (comment) & #395 with this style of update.

Major changes

  • lualine now refresh based on timer + some auto-commands.
  • added require('lualine').refresh function to force refresh lualine . It can refresh all statusline, tabline, winbars or can granularly refresh specific statusline/tabline/winbar of specific windows see the code docs for more info.
  • winbar support. (originally form feat: add winbar support #689 by @diegodox)
  • winbar support in extensions.
  • newly added options
    • options.refresh.statusline
    • options.refresh.tabline
    • options.refresh.winbar
    • options.disabled_filetypes.statusline
    • options.disabled_filetypes.winbar
    • winbar
    • inactive_winbar
  • various bug fixes.

known Issues/todos:

  • Refresh time is set to 1s . It seems when changing wins inactive & active stls don't switch immediately instead takes that 1s to update which is quite noticeable . Possible solutions: utilize autocommads to refresh on such events.
  • We need to handle errors in the refresh funcitnon so if we say fail to update 3 times in a row we should stop the timer.
  • looks like nvim wants to put winbars on floating windows too. but it might fail if there aren't enough room like telescopes prompt . that's an issue for us. wonder if we can determine if a win is float or not and skip floats 🤦‍♂️ (skiping winbar on winheight <= 1 & floating windows)
  • try merging statusline_dispatch and winbar_dispatch togather they have a lot of duplication
  • statusline doesn't seem to update regularly in cmdline mode
  • nvim-0,5 & 0.6 is broken with nvim_opts module . (may we should just have compat tags for older nvim version and be done with them . keeping support for them is getting annoying )
  • live update seems broken for gobalstatus & separators options.
  • yes we have that intro disappearing due to redraw issue again.

closes #744 #692
supersedes #689

@shadmansaleh shadmansaleh force-pushed the feat/refresh_on_timer branch 2 times, most recently from e800bcb to 38cfa16 Compare July 12, 2022 07:56
@shadmansaleh shadmansaleh mentioned this pull request Jul 12, 2022
Closed
@lkhphuc
Copy link

lkhphuc commented Jul 12, 2022 •
edited
Loading

Hi, compare to the #689, this PR doesn't respect the configs.options.disabled_filetypes option. The result I got is the winbar_inactive components still get displayed in e.g "TelescopePrompt", "floaterm", even though they have been added to ignore list.
Edit: cmp completion floating windows too

@shadmansaleh
Copy link
Member Author

shadmansaleh commented Jul 12, 2022 •
edited
Loading

I don't think that's the case here. We are respecting disabled filetypes but It seems telescope is creating 6 windows but it only marks 2 of those with filetype TelescopeResults and TelescopePrompt. I'm not using floaterm but toggleterm seems to work correctly with disabled_filetype. Maybe floaterm does something similar to telescope.

Also it seems floating windows don't use global value of winbar option so in previous pr floating windows didn't have winbar at all even without you adding the filetypes to disabled list

@lkhphuc
Copy link

lkhphuc commented Jul 12, 2022

Also it seems floating windows don't use global value of winbar option so in previous pr floating windows didn't have winbar at all even without you adding the filetypes to disabled list

I wonder if this is desired behaviour in most case.

@shadmansaleh
Copy link
Member Author

shadmansaleh commented Jul 12, 2022 •
edited
Loading

I wonder if this is desired behaviour in most case.

Ok now we are ignoring floating windows . telescope should appear correctly now but it also means no winbar on floating windows from lualine.

@shadmansaleh shadmansaleh mentioned this pull request Jul 12, 2022
Closed
@shadmansaleh shadmansaleh added enhancement General improvements or improvement request discuss labels Jul 12, 2022
@lkhphuc
Copy link

lkhphuc commented Jul 13, 2022 •
edited
Loading

Another thing I notice is that this with this branch, my showtabline is set to 1, even though I have vim.o.showtabline=0 in my config.
On my config it display some very ugly tabline when I have 2 tabs or more, as I don't use/config in lualine, nor anywhere.

@shadmansaleh
Copy link
Member Author

@lkhphuc I think a bug in neovim is causing the issue you're facing . I've opened an issue in neovim's repo neovim/neovim#19464 lets what the devs think about it.

@shadmansaleh shadmansaleh changed the title feat: refresh lualine based on timer. (experimental) feat: refresh lualine based on timer + winbar support. (experimental) Jul 22, 2022
This was linked to issues Jul 22, 2022
Feat: Winbar support #692
Closed
Feat: global statusline should still displays for all filetypes, including ignored_filetypes #744
Closed
@shadmansaleh
Copy link
Member Author

I think this branch is quite stable . I can probably merge it already . I anyone want can take it for a spin and see if there are any inconsistencies.

@shadmansaleh
fix: winbar some times oddly throwing errors
18dd214 
about not having space in floating windows.

This implements a temporary workaround the issue(neovim/neovim#19464)
until the bug in neovim gets fixed.
@shadmansaleh shadmansaleh merged commit 53aa3d8 into master Jul 22, 2022
@shadmansaleh shadmansaleh deleted the feat/refresh_on_timer branch July 22, 2022 13:29
@shadmansaleh shadmansaleh changed the title feat: refresh lualine based on timer + winbar support. (experimental) feat: refresh lualine based on timer + winbar support. Jul 22, 2022
@willnorris
Copy link

This seems to be causing a problem with set wildmode=list... the command line completion list displays for just a second, and then disappears. Reverting to 8d956c1 fixes the behavior, so it definitely seems to be caused by this.

@shadmansaleh
Copy link
Member Author

@willnorris fixed in 6fbc35b

@shadmansaleh shadmansaleh mentioned this pull request Jul 24, 2022
Merged
@numToStr numToStr mentioned this pull request Jul 25, 2022
Closed
2 tasks
@lkhphuc lkhphuc mentioned this pull request Jul 25, 2022
Closed
2 tasks
@eeeXun eeeXun mentioned this pull request Jul 30, 2022
Closed
2 tasks
@vimpostor vimpostor mentioned this pull request Aug 7, 2022
Closed
vimpostor added a commit to vimpostor/vim-tpipeline that referenced this pull request Aug 7, 2022
@vimpostor
Postpone evaluation of stl for nvim
affe9ca 
Usually the statusline is set once at the startup of vim to a function
that evaluates to the dynamic value of the statusline at runtime.

However some statuslines are particularly retarded and completely shit
on this vim idiomatic way of setting the statusline and instead update
the stl vim option directly, e.g. with a timer and on autocmd events.

This is not only completely stupid, but also has slightly worse
performance and is in fact also semantically incorrect (e.g. there is
not an autocmd for every way that it is possible to update the
statusline, only for most of the scenarios).

This is now the second time that lualine does something in a completely
fucked up way (the first time was the way that they pretend to have
global statusline support, by simply setting the laststatus option if a
lualine option is set, completely ignoring the idiomatic way of simply
letting the user set the laststatus option directly).
Why again are so many people recommending lualine?
They seem to know jack shit about the idiomatic way to do things in vim.

The bad commit in lualine is 53aa3d82d9d9329880b4197f278fcb74051a6af5.

Of course this also breaks our plugin because of the way that
g:tpipeline_statusline interacts with &stl.

To workaround the issue, we do not set g:tpipeline_statusline if we are
in neovim. Then in the update routine we first evaluate
g:tpipeline_statusline (to not break users configs that set this
variable) and then try &stl as fallback.

For now we only implement this workaround for neovim, as I don't believe
there is any vim statusline plugin that uses stl in such a fucked up
way.

Congrats lualine, we know have an extra workaround just for you.

Fixes #32

ref: nvim-lualine/lualine.nvim@53aa3d8
ref: nvim-lualine/lualine.nvim#736
@matheussampaio matheussampaio mentioned this pull request Oct 4, 2022
Open
@vimpostor vimpostor mentioned this pull request Feb 26, 2023
Closed
vimpostor added a commit to vimpostor/vim-tpipeline that referenced this pull request Feb 26, 2023
@vimpostor
Subscribe to all statusline OptionSet events
4d8acfd 
This isn't really necessary for any sane statusline. But of course this
is a world where lualine exists.

Lualine is using a cursed timer-based update [0], where they update the
statusline option directly instead of using a function indirection like
literally every single sane statusline plugin in existance.

As I have explained several times in the past, this introduces many
problems, even for vanilla lualine users without any other plugin
involved (e.g. some statusline updates will not trigger lualine's
timer-based update, so even vanilla lualine may sometimes have a slight
lag).

This is now the third time that lualine's inability to follow basic vim
idiomatic patterns has caused us painful regressions [1].
In this case the regression occurred because there seems to be an
autocmd order conflict, which causes tpipeline to miss the most recent
statusline update and lag behind exactly one iteration.

Lualine should just switch back to the sane function indirection
pattern, but these days a majority of neovim plugin devs seem to be
completely immune to following vim best practices...

Fixes #50

[0] nvim-lualine/lualine.nvim#736
[1] See commit affe9ca
craigmac pushed a commit to craigmac/lualine.nvim that referenced this pull request May 15, 2024
@shadmansaleh @diegodox @craigmac
feat: refresh lualine based on timer + winbar support. (nvim-lualine#736
8fef42e 
)

* feat: refresh lualine based on timer.

* fix config test

* fix lag on win change issue

* handle errors in timer callback

* feat: add winbar support

Pull in winbar changes form pr nvim-lualine#689 and adapt them
Co-authored-by: shadmansaleh <13149513+shadmansaleh@users.noreply.github.com>

* make winbar disapear when winbar evals empty

* only update stl of curwin with globalstatus

* properly clear win local stl and wbr opts

* add version guards for winbar feature

* only add winbar if height > 1

* fix tests?

* refresh lualine on ModeChanged event

* ignore floating windows for refresh

* properply restore options to previous state

* fix stl not updating in cmd mode + some optimizations

* fix tests on <nvim-0.7

* merge status_dispatch & winbar_dispatch + winbar support for extensions

* fix globalstatus option not live updating

* update docs

* feat: allow disabling winbar and statusline separately

* fix tests

* fix: winbar some times oddly throwing errors

about not having space in floating windows.

This implements a temporary workaround the issue(neovim/neovim#19464)
until the bug in neovim gets fixed.

Co-authored-by: Diego Fujii <android.mxdiego9@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
discuss enhancement General improvements or improvement request
Projects
None yet
Milestone
No milestone
4 participants
@shadmansaleh @lkhphuc @willnorris @diegodox