Complex input "form"

[danielo515]

Hello, thanks for this great library.
I was wondering if it would be possible to create a complex UI form (which I assume it is) and what the limitations would be.
What I want is, one input (one row)
Below one text-area (I assume this should be just a popup with an editable buffer),
Then maybe some kind of menu with confirm/cancel options
And last, a little non-focusable area with help.
I want the form to jump to the next actionable item when pressing enter/tab and get all the information at the end.
I assume I will have to do some vim tricks, but I was wondering how much of that can nui abstract away .

Regards

[danielo515]

So I have been playing with this a bit, and I have found some limitations that make me think the library is not meant to render several ui elements at the same time.
Many of the methods are not available until the element is mount, and some sizing coordinates are not calculated either.
This makes a bit cumbersome to render elements that are relative to each other, having to resort to variable declarations, weird mount ordering and that stuff. I'll post more details later

[cseickel]

I would say that (neo)vim in general works on the concept of one question at a time, and the process of obtaining the answers to multiple questions usually follows a wizard approach where each question as asked one at a time in a chain. Nui fits into this model with the current set of features. I am not aware of any alternative that would work well for a form based approach.

[MunifTanjim]

Right now, creating complex layout is a completely manual process. You'll need to calculate the positions of various components yourself.

But it will get easier in the future, check: #18.

I already started working on it: #120, but can't promise when it'll be finished.

[danielo515]

Is the recently added Layout component a solution for this problem?

[danielo515]

I think it is, given the example in the PR:

local layout = Layout(
  {
    position = "50%",
    size = {
      width = 100,
      height = 20,
    },
  },
  Layout.Box({
    Layout.Box(popup1, { size = "20%" }),
    Layout.Box({
      Layout.Box(popup3, { size = "40%" }),
      Layout.Box(popup4, { size = "60%" }),
    }, { dir = "col", size = "60%" }),
    Layout.Box(popup2, { size = "20%" }),
  }, { dir = "row" })
)

layout:mount()

Please consider adding this as advanced examples to the documentation of Layout component

[danielo515]

Yo, here is a bit more detailed report of which problems have faced so far.
So, one of the first problems I realised is that, when relative values are given (50% etc) those values are not calculated until the component is mounted. That makes impossible to define all the components relative to each other first and then mount them. You have to define one component, mount it, and then define the next in terms of the previous, then mount it, etc.
Another problem I've found is that you can not map keybindings until the input has been mounted, so that is another little problem I had, which is also preventing me from binding in the order I wanted.

My expectation was something like this:

local input1 = Input(input_options, {})
local popup1 = Popup(popup_options) -- This includes relative row and col from input 1
local popup2 = Popup(popup_options_including_popup1_stuff) -- same as above but from popup1


input1:mount()
popup1:mount()
popup2:mount()

But instead I have to do it like this

local input1 = Input(input_options, {})
input1:mount()
local popup1 = Popup(popup_options) -- This includes relative row and col from input 1
popup1:mount()
local popup2 = Popup(popup_options_including_popup1_stuff) -- same as above but from popup1
popup2:mount()

With obviously a lot more logic in between.

In order to keep things as close as possible I also tried mapping things in the WinEnter event but it fails. It seems that the win enter event is triggered before the component can be considered mounted, so I can't do this:

---Binds the requested keys to the available actions withinthe contex of the provided popup
---@param mode 'n'|'i'
---@param binds { switch_key: string|string[], exit_key}
---@param popup Popup
---@param alt_win integer alternative window to jump on switch
local function bindKeys(mode, binds, popup, alt_win)
  local opts = { noremap = true }
  local function map(key, cb)
    popup:map(mode, key, cb, opts)
  end

  if not vim.tbl_islist(binds.switch_key) then
    binds.switch_key = { binds.switch_key }
  end
  for _, key in ipairs(binds.switch_key) do
    map(key, function()
      vim.api.nvim_set_current_win(alt_win)
      vim.cmd('startinsert')
    end)
  end
  map(binds.exit_key, exit)
end


-- Mount the popup only after the input has been mounted
input:on({ event.WinEnter },
  function()
    layout.popup:mount()
    layout.help:mount()
    -- bindKeys('n', { switch_key = '<Tab>', exit_key = 'q' }, layout.input, layout./popup.bufnr) -- <- THIS FAILS
    bindKeys('n', { switch_key = '<Tab>', exit_key = 'q' }, layout.popup, layout.input.bufnr)
  end, { once = true })

I came to the conclusion that I will be better doing the row and column calculations myself rather that relying on the built in ones. That way I will be able to get all the relative positioning, configure all the components and then mount them all at once without introducing that much dependencies between each other. I still miss some more declarative helpers, because I still have to wait to the components to mount in order to map keymaps to them AND be able to access their window IDs (which I need to alternate window key-bindings)

Hope you can give me some guidance about having a more declarative way of doing all this before I start trying to build my own abstraction on top of your library.

[danielo515]

OK, this is full of wrong assumptions. Please ignore it for now, I'll re-check it and write it again.