neovim / neovim

Vim-fork focused on extensibility and usability
https://neovim.io
Other
81.13k stars 5.55k forks source link

UI: more control over statusline, tabline #15432

Open iasj opened 3 years ago

iasj commented 3 years ago

Feature already in Vim?

I don't think so.

Feature description

Hi there.

I've been following the issues segment for quite a while, and even posted a few requests myself: here, here, and here.

The thing is, I'm building a collection of plug-ins and since they are growing in number, I fear I won't be able to move forward with some ideas because of some limitations.

Limitation number 1 (global tabline)

This limitation only affects the looks in one the my plugins, but it may be important in the future for other ones. The plugin is called Zoom and it's nothing more than a distraction-free implementation. The thing is, Zoom gives support to another one of my plugins now call nvpm, which is gonna be broken down into more plugins soon.

The problem itself is regarding the fact that the tabline is unique to all buffers. The "problem" can be seen in the following screenshot:

zoom

You can see that the tabline occupies the whole width of the screen, whereas the statusline is only local to the buffer in the middle.

Solution I want: I want to be able to set the tabline to apear only on the focuses buffer (the one in the middle in the shot above). Moreover, the command-line is also global, and it would be perfect to have it occupy only the width of the focused buffer, right below the statusline.

Limitation number 2 (statusline on every buffer)

I've described here that this would be perfect for a future implementation of splits, in my plugin now called nvpm. This plugin will be split into others, amongst them there will be one called line, which would then need this feature.

Solution I want: I would love to be able to have more control over where to draw the statusline. For example, I'd like to set it in a specific position and also to set it's width. This way I would handle splits better in those plugins. It's a feature that I really want to implement, but I already know it's gonna be impossible.

This problem also affects the zoom, because I'd also like to have the statuslines from the padding buffers to be canceled, because they consume part of the usable width and height. For now I'm only handling their highlighting to make them appear to have vanished, but they're still there.

Limitation number 3 (no mouse handling for statusline)

I only knew this was an issue when I saw this, and I'm not sure if it is already possible.

This would also improve and increase the use cases of some of my plugins. I'm preparing to implement a mouse event handling, and I fear to have this as a problem.

Solution I want: to have mouse support for MouseClick, MouseScroll, and MouseHover (if possible) for both tab and status lines.

I've thought of this use case to be in such a way that you gonna be able to do a lot just by moving the mouse around.

Well, I hope I was clear enough. I also understand that there is currently 1.2k opened issues, so I'll definitely understand if I never get a reply for this. In any event, I appreciate any efforts on making this real.

with regards, Itamar Soares

justinmk commented 3 years ago

Solution I want: to have mouse support for MouseClick, MouseScroll, and MouseHover (if possible) for both tab and status lines.

Nvim tabline supports mouse clicks: https://github.com/neovim/neovim/pull/3871 , via the %@Func@ format. You found https://github.com/neovim/neovim/issues/11924 so I guess you know already :)

:help 'statusline' :

    @ N   For 'tabline': start of execute function label. Use %X or %T to 
          end the label, e.g.: %10@SwitchBuffer@foo.c%X.  Clicking this 
          label runs specified function: in the example when clicking once 
          using left mouse button on "foo.c" "SwitchBuffer(10, 1, 'l', 
          '    ')" expression will be run.  Function receives the 

Moreover, the command-line is also global, and it would be perfect to have it occupy only the width of the focused buffer, right below the statusline.

Maybe could be hacked with clever highlights.

If you want full control over the statusline, the current answer is to implement a custom UI.

Proposal

Instead of adding more features to 'statusline', it could optionally be driven by a user-defined floating window/buffer.

iasj commented 3 years ago

You found #11924 so I guess you know already :)

Yeah I found. Since it still doesn't have support for the statusline as well, I'm afraid the use case I intend would be incomplete, so I won't even bother to implement it for now.

If you want full control over the statusline, the current answer is to implement a custom UI.

I was thinking the same thing, but I was in denial. I couldn't believe I was gonna have to do this. But yeah, good point.

Proposal Instead of adding more features to 'statusline', it could optionally be driven by a user-defined floating window/buffer.

Yeah, I heard about those floating window/buffers somewhere, but I never really found it in the docs. Do you know where?

By the way - making use of this message - here is a shot of what I meant for the local tabline:

zoom2

I'm faking a zoom mode with tmux panes around the pane in the middle. That's the same strategy I use in the zoom plug-in, but with Vim buffers instead of tmux panes.

iasj commented 3 years ago

Yeah, I heard about those floating window/buffers somewhere, but I never really found it in the docs. Do you know where?

I think I found a great tutorial on the matter. No wonder I haven't found in the docs, for I was looking for tutorials using the string :help float<tab>. I'll definitely look into this.

danielo515 commented 2 years ago

Instead of adding more features to 'statusline', it could optionally be driven by a user-defined floating window/buffer.

Doesn't floating windows obscure/hide part of the buffer/window you have focused? Even if it just one line, it can get messy if you can not get to the bottom of your file

bfredl commented 2 years ago

@danielo515 yes, we would need a new positioning mode to properly allocate space from the parent window with no occlusion

danielo515 commented 2 years ago

@danielo515 yes, we would need a new positioning mode to properly allocate space from the parent window with no occlusion

That sounds very interesting. If you allow that, that will open the possibility to have "metadata/child" windows in any position right? That may be awesome. Will those windows be attached to the parent one? Meaning I can move the parent window and they will move with it,or close the parent window and that will close the attached windows?