Fix non-refreshing on lualine changing to command mode

[dzirtusss]

Bug:

1. Using Lualine + tpipeline, macos
2. When switching from NORMAL to COMMAND mode (by just pressing :) in most cases changes to status bar are not picked up by tpipeline. Only very rarely it picks up correctly.
3. When switching other modes I haven't noticed such behaviour, but I haven't tested that much.

Switching to delayed variant fixes all.

IMO, this is rather safe as practically doesn't change anything in logic but works better with race.

[vimpostor]

This is effectively a revert of c380544, I need to make sure that this doesn't regress #51, but quite frankly I am a bit fed up with all the workarounds necessary for lualine.
If this is merged, the commit should be created with git revert c380544 and the commit message should explain why the revert is safe.

[dzirtusss]

Yep 😞

However, other discussion in #53 (comment) let me think that not only Lualine is a problem (which definitely is the root of all evil statusline rewrites) but lazy as well. And I've cahnged to:

-- for lazy.nvim config
{ 'vimpostor/vim-tpipeline', event = 'VeryLazy'}

Which basically forces lazy to load tpipline after all other plugins, and (at least in my case) all problems have gone fully. Even stl workaround is working as it should.

From https://lazy.folke.io/usage#-user-events

VeryLazy: triggered after LazyDone and processing VimEnter auto commands

I mean fortunatelly or unfortunatelly lazy and lualine are popular choices many people use, and at least for me personally lualine theme, aestetically plays well with my tmux poweline theme:

And lazy 🤷‍♂️ maybe I want to switch it eventually, but this will need all config rewrite, and overall I don't have any other problems with it.

So... I guess better just add notes in the readme file about lazy.nvim / lualine combo, so that other people don't repeat that. I mean atm, I can't imagine why VeryLazy can't be a default config option for tpipeline + lazy.nvim

WDYT?

[vimpostor]

So... I guess better just add notes in the readme file about lazy.nvim / lualine combo, so that other people don't repeat that. I mean atm, I can't imagine why VeryLazy can't be a default config option for tpipeline + lazy.nvim

That feels so backwards to me. Why should I add a note for every plugin that behaves in a bad way to my README? The plugins should add that note to their own README.

lualine does not mention anything in the README and lazy.nvim only mentions it in a hidden place:

lazy.nvim does NOT use Neovim packages and even disables plugin loading completely (vim.go.loadplugins = false).

It never mentions that this can have unintended sideeffects, and conveniently only mentions that this may have better performance (every sane plugin already uses the autoload mechanism though, so this "optimization" is just snake oil).

WDYT?

It's not my job to warn about every bad plugin out there. The bad plugins should clearly mention the sideeffects they can have.

[dzirtusss]

It's not my job to warn about every bad plugin out there. The bad plugins should clearly mention the sideeffects they can have.

In an ideal world I'd agree with you man. In real... I guess just better to help people vs being right. Having a README (or line in FAQ.) as:

Installation

Using vim-plug:

Plug 'vimpostor/vim-tpipeline'

Using lazy.nvim

{ 'vimpostor/vim-tpipeline', event = 'VeryLazy' } -- VeryLazy is important if you use Lualine

most probably will solve me installation hassle. And for you - free your time for answering stupid reccuring topics about Lualine. And increase plugin adoption - I mean, lucky for me I had some time to play with it, but honestly most probably if it doesn't work with main configs I do check readme, very rarely issues, and quit.

Anyway, thank you for this plugin - it finally works as intended for me.

[vimpostor]

In an ideal world I'd agree with you man. In real... I guess just better to help people vs being right.

I honestly don't see a problem with trying to strive for an ideal world. Helping people with a suboptimal solution is only good short-term, the ideal solution always pays off more over time.

But even if you were right, many people do not even read the README, so adding further user instructions to the README won't help the case. I would even prefer adding yet another lualine workaround over adding more instructions.
I will have to take a look at what the best solution is here (and maybe it is this PR), but I don't have the time right now.

[dzirtusss]

Just for experiment, I've ensured that tpipeline hook is always after lualine's hook, and it works beautifully so far with any setup and w/o VeryLazy, etc. "specials".

Atm it only pushes tpipeline hook to the last one. And g:tpipeline_statusline need to be handled more correctly for stl. But that's proof of concept only. And only ModeChanged hook check is needed.

vim.api.nvim_create_augroup('FixStatuslineHooks', { clear = true })
vim.api.nvim_create_autocmd('ModeChanged', {
  group = 'FixStatuslineHooks',
  callback = function()
    local autocmds = vim.api.nvim_get_autocmds({ event = "ModeChanged" })
    local last = autocmds[#autocmds]
    if last.group_name == 'tpipeline' then return end

    vim.cmd([[
      augroup tpipeline
      autocmd!
      augroup END

      if g:tpipeline_clearstl
        let g:tpipeline_statusline = ''
      endif

      call tpipeline#build_hooks()
    ]])
  end
})

I mean, maybe it is not the best way how plugins should work, but maybe you can build-up on this idea something more proper when you'll have time.