feline.nvim icon indicating copy to clipboard operation
feline.nvim copied to clipboard

[Feature] Feature request: component stack

Open mawkler opened this issue 2 years ago • 10 comments

Is your feature request related to a problem? Please describe. My statusline has three sections. I like to have a couple of different indicators in the middle of my statusline, but only showing one at a time. My middle section defaults to showing nvim-gps (haven't had time to switch to nvim-navic yet), but for instance, whenever I have a snippet active it shows <> snippet in the middle. With the new macro provider I would now like for it to show the macro provider whenever it is active. Remember, I only want one to be displayed at a time and would therefore like for them to be prioritized in this order: macro > snippet > gps.

I think this idea would be useful to more people that have a lot of components in their statusline that don't necessarily need to be displayed simultaneously.

Describe the solution you'd like A component stack. An example of how this could be implemented is to allow the component field provider to be a table of components. Feline goes through the table left to right and evaluates its enabled, and the first one that is true is drawn. All other components are not drawn.

Describe alternatives you've considered My current solution is just an ugly hack. I tried to properly implement a stack myself in my config but it quickly became quite complicated.

mawkler avatar Nov 11 '22 11:11 mawkler

Why not just use a single provider that picks the correct provider?

famiu avatar Nov 11 '22 16:11 famiu

That was what I tried but the problem is that they all need different values for the hl and icon fields. What I did was to make the enabled field tell one of the components to be enabled depending on the priority mentioned above, but they also need their own individual enabled, for instance the macro component should only be shown when a macro is being recorded.

This is of course possible to solve now but I found that it quickly became an ugly mess when I tried. I totally understand if you don't want to add this feature to feline.nvim but I thought that I should bring it up because I think that other users might find a feature like this usefull as well.

Perhaps a simpler solution would be to add the ability to include functions that return a component in the table of components passed to setup()?

require('feline').setup({
  components = {
    active = {
      {
        {...},         -- Component 1
        {...},         -- Component 2
        function()
          return {...} -- Component 3
        end,
      }
    }
  },
})

mawkler avatar Nov 12 '22 12:11 mawkler

How about adding component groups instead, which allows you to have several components share certain properties while differing in others?

famiu avatar Nov 13 '22 01:11 famiu

That sounds like a good idea but I'm not quite sure how it solves my particular problem. Could you show an example of how they would be used?

mawkler avatar Nov 15 '22 07:11 mawkler

That sounds like a good idea but I'm not quite sure how it solves my particular problem. Could you show an example of how they would be used?

So it would be something like this:

{
  hl = { fg = 'white', bg = 'black' },
  enable = function() return #vim.api.nvim_list_wins() >= 2 end,
  left_sep = ' ',
  right_sep = ' ',
  -- All components within this group share the same `hl`,  `enable`, `left_sep` and `right_sep` values
  {
    provider = my_provider
  },
  {
    provider = my_other_provider
  }
}

famiu avatar Nov 15 '22 14:11 famiu

Ok but how would I use this to enable only one component/provider at a time?

mawkler avatar Nov 15 '22 16:11 mawkler

Ok but how would I use this to enable only one component/provider at a time?

Have different (mutually-exclusive) enabled and provider fields for all of them?

famiu avatar Nov 15 '22 16:11 famiu

Ok I see. The difficult part however is making them all mutually-exclusive.

mawkler avatar Nov 16 '22 07:11 mawkler

Ok I see. The difficult part however is making them all mutually-exclusive.

I understand. The issue is, the usecase you provided is likely very rare, so it probably isn't worth the cost for adding component stacks for a very specific and uncommon usecase. Component groups might be a better, less convenient but more general solution

famiu avatar Nov 16 '22 14:11 famiu

I understand 🙂

mawkler avatar Nov 16 '22 16:11 mawkler