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.

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

Hide Incline when there is just one window #3

Closed
rubenmate opened this issue Apr 18, 2022 · 8 comments
Closed

Hide Incline when there is just one window #3

rubenmate opened this issue Apr 18, 2022 · 8 comments
Labels
enhancement New feature or request

Comments

@rubenmate
Copy link

Hello there!

I'm loving the plugin, it's really handy with the new global status bar.
My only problem with it is that I see no point in showing it when there is just one window (expected behaviour for me is: 1 window => Hide | 2 or more windows => Show)

I have cloned it and tried to implement it myself but not there yet 😅

Maybe you feel this is not necessary, feel free to close it then!

Have a nice day and thanks for the plugin!

@gegoune
Copy link

gegoune commented Apr 18, 2022

  hide = {
    focused_win = true,
  },

should take care of single window, shouldn't it?

@b0o
Copy link
Owner

b0o commented Apr 18, 2022

Yeah the option @gegoune mentioned should work. Give it a try and let me know if that’s what you’re looking for?

@pianocomposer321
Copy link

Just to chime in, I'm not currently using this plugin (though I am planning to give it a shot), but I can imagine situations where I wouldn't want it to be hidden every time a window is focused, only when there's only one window open. For example, when the top window of a horizontal split is focused, just looking at the bottom of that window is easier and more intuitive than looking all the way at the bottom of the screen, so I probably wouldn't want the status line hidden in that case. But if there's only one window open, the floating status line is going to be redundant, and the bottom of the window is where the main status line is anyway. So I still think it would be helpful for this to be an additional option.

@b0o
Copy link
Owner

b0o commented Apr 18, 2022

That is a great point and I agree, @pianocomposer321. I’ll add this to the backlog.

@b0o b0o added the enhancement New feature or request label Apr 18, 2022
@b0o
Copy link
Owner

b0o commented Apr 21, 2022

Does anyone have thoughts on how this proposed option should behave when there is more than one window, but only one non-ignored window?

For example, if you open the file foobar.lua in one window and nvim-tree in another window, and if you have ignore.buftypes = "special", then there would effectively be only one non-ignored window. If the proposed option was enabled, should Incline be shown or hidden on the foobar.lua window?

@pianocomposer321
Copy link

Hmm...that is an interesting question.

TBH, I feel like this would be good as two separate options. Or an option with an "enum"-style value. But if you don't want to implement two separate options (or just one at a time), I think that it should be hidden when it's the last non-ignored window. The main issue with this would be if a window is ignored with incline but not for the main statusline (meaning that when it's focused you wouldn't be able to tell the name of the file in the non-ignored window), but leaving that up to the users to fix doesn't seem entirely unreasonable.

Of course, having two separate options still seems like the best approach to me.

@akinsho
Copy link

akinsho commented Apr 21, 2022

Just jumping in regarding the two separate options. I'm currently using the plugin and really enjoying it with the current focused win option I'd much rather retain the current behaviour, i.e. the buffer I'm in should never have a label since my statusline will always show it. Trying not to muddy the waters but advocate for a different option that does what @pianocomposer321 proposed but also keeping the ability to have the plugin behave as it currently does.

@pianocomposer321
Copy link

@akinsho I just want to clarify, because I know this has gotten a bit confusing, and I think my last comment probably is the source of a lot of it. There are actually a total of three options being discussed right now - focused_win, which already exists, and two more (I'll just make up names because they haven't been implemented yet): last_win and last_nonignored_win. The final two are the ones that I was saying I think should be two separate options, with the latter being the one I thought was more important if only one of them gets implemented. I completely agree that focused_win should be left as-is.

@b0o b0o closed this as completed in f353839 Apr 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants