[RFC] Floating windows in TUI and Remote UI

[bfredl]

From the drawer of very naive and crazy stuff (one does not simply mess with window positioning and expect stuff to work). Partially based on @dzhou121 external ui stuff (crazy/naiveness mine)

do this in a script:

fnew
call nvim_win_float_set_pos(0,5,10,20,5)
hi Floating guibg=#000044
set winhl=Normal:Floating
set nonumber

[johnzeng]

hi, will this PR be merged? or, still wip?

[bfredl]

Is still WIP, many window commands can easily segfault, and the mouse is broken. Also we need a better redrawing strategy than "redraw the float everytime anything else is redrawn". Probabaly should use some buffering logic from #5686

[johnzeng]

Good to know that. I am waiting for it.

[bfredl]

Update: replaced fnew with api command:

Window nvim_open_floating_window(Buffer buffer,
                                 Integer x, Integer y, Integer w, Integer h,
                                 Integer mode, Boolean enter, Error *err)

mode supports anchor modes (will be relevant for UIs with different grid sizes in floats) as well making the window "unfocusable". It is still possible to make it current with api or number, but the user selecting it "by accident" with mouse or ctrl-Wctrl-W should be avoided.

Also added very basic mouse support.

[justinmk]

I'd suggest "new" as the standard verb for creating things. Also in API functions we always spell "window" as win.

nvim_new_floating_win

[bfredl]

new isn't verb though. The alternative would be add, but open signals something more heavy (as a window or channel is) than something you just add to a set like a line or a highlight. create might also work and is slightly more general (like nvim_create_namespace )

[justinmk]

new acts like a verb in many programming languages. It has wide recognition, it's short, strong, and familiar.

[bfredl]

My point was primarily about operation strength, not grammar. Opening/Creating a new window or buffer (or channel) is a lot heavier than adding a new line (we call it [o]pen only because [n] was taken for [n]ext) or highlight, or allocating a new object in "many programming languages". These are all different verbs for a reason. (and if we're discussing common languages, new string() vs string() in javascript is just madness, while in modern c++ well-typed pointers is preferred to new/delete)

[bfredl]

Added nvim_add_buf(). Note it only adds a buffer to the buffer list, they are not opened/allocated until they are displayed in some window.

let b = nvim_add_buf("")
let w =  nvim_open_floating_window(b,5,10,20,5,0,0)
hi Floating guibg=#000044
call setwinvar(w, '&winhl', 'Normal:Floating')
call setwinvar(w, '&number', 0)

[wsdjeg]

This PR is awesome, and I have a question about the floating window, I just see the doc what dese Integer x, Integer y, Integer w, Integer h, base on? computer's screen or vim's screen?

[justinmk]

nvim_open_floating_win

[justinmk]

nvim_add_buf

Here "new" as the verb makes sense to me: nvim_new_buf(). We're creating an object. The buffer list is like a vtable (an implementation detail) so "add" isn't the characteristic operation.

[bfredl]

The buffer list most definitely not an implementation detail: it is well known and used vim functionality that a buffer can be "listed" without actually being "opened". The API functions current operation is only to add/return a number in the buffer list, but "add" might not be the best either, as it can return an existing buffer.

However, that is not necessarily the best operation, we could have a function that only creates a new (unnamed) buffer and fully allocates it (this special case might not need to make it temporarily displayed, as there is no swapfile, encoding errors, and probably we want no autocmds either) The current behavior makes sense in the "floating window" case given that it will immediately opened in a window anyway, at which point all the vim stuff happens.

[ZyX-I]

I have a suggestion: either make x and y Float and allow negative and fractional values, or add another argument which specifies what x and y are related to and what they actually mean. Neither makes sense for TUI, but GUI may open windows outside of the window.

Or do the other thing: open_floating_window already contains lots of arguments. Make that dict:

/// Open floating window
///
/// @param[in]  buffer  Buffer to display in that window.
/// @param[in]  position  Window position, pair of two integers which may be 
/// negative.
/// @param[in]  options  Additional options:
///                      Option | Type | Description
///                      ------ | ---- | -----------
///                      anchor | String | Make position be relative to the 
///                             |        | given anchor: "type-pos" where "type"
///                             |        | is one of "screen", "editor_area",
///                             |        | "wm_window" and "pos" is one of "NW",
///                             |        | "NE", "SW" or "SE"; additionally
///                             |        | "cursor" position is supported.
///                             |        |
///                             |        | Defaults to "cursor".
///                             |        |
///                             |        | TUI only supports "editor_area-…" and
///                             |        | "cursor".
///                      dimensions | pair of Integers | Dimensions in screen
///                                 |                  | cells, width x height.
///                                 |                  |
///                                 |                  | Defaults to either just
///                                 |                  | enough to show the
///                                 |                  | whole buffer contents
///                                 |                  | (not updated when
///                                 |                  | buffer contents
///                                 |                  | changes, call
///                                 |                  | `nvim_reconfigure_floating_window({dimensions: NIL})`
///                                 |                  | then), or just enough
///                                 |                  | to occupy all available
///                                 |                  | space, whichever is
///                                 |                  | lesser.
///                      standalone | Boolean | Make window standalone.
///                                 |         |
///                                 |         | Defaults to false, may be
///                                 |         | ignored in TUI.
///                      focusable | Boolean | Make window not focusable, and
///                                |         | also ignore mouse events.
///                                |         |
///                                |         | Defaults to false.
///                      position_type | String | Position type: either "cells"
///                                    |        | (position in display cells) or
///                                    |        | "pixels".
///                                    |        |
///                                    |        | Defaults to "cells" for
///                                    |        | "editor_area-*" and "cursor"
///                                    |        | anchors, "pixels" otherwise.
Window nvim_open_floating_window(Buffer buffer, ArrayOf(Integer) position,
                                 Dictionary options, Error *const err)

/// Reconfigure floating window
///
/// @param[in]  window  Window to reconfigure.
/// @param[in]  options  @see nvim_open_floating_window()
///                      Missing values mean “do not change option”, use NIL to 
///                      force defaults.
void nvim_reconfigure_floating_window(Window window, Dictionary options,
                                      Error *const err)

[justinmk]

The buffer list most definitely not an implementation detail: it is well known and used vim functionality

It's an irrelevant detail in the context of the API. When one creates a buffer one does not think "I want to add a buffer to the buffer list", only "I want a new buffer".

[bfredl]

Again, the name describes what the function does right now, which was the simplest thing to implement. The relevant change would be to change what the function actually does (fully allocate a buffer), which will be more involved but probably worth it in the long run.

[chemzqm]

I think a function for close preview window or close window without focus is needed.

I can close the preview window by wincmd c but it requries focus the preview window, the problem is when the user have selected region at this time the change of focused window break current selection.

[bfredl]

:[winnr]close can be used, but it is not very convenient. We could add nvim_win_close([winid]) which works the same but with winid.

[bfredl]

Working on the last issues, ci build is aalmost passing now. I plan to merge this today or tomorrow. It is usable enough as a MVP (as demonstrated by plugins adding support already). The API/functionality (and tests with them) can be expanded in follow-up PRs.

[bfredl]

Merged. Sorry for taking so long. I will lock this thread, as dealing with overlong github threads is a mess. Requests for additions/improvements (or bugs too minor to deserve their own issue) can be in #9421. Feel free to repeat stuff that is hidden somewhere in the middle of this thread and still are a concern.