Option for padding in winopts

[carloscalla]

Hi, in very rare occasions I have to deal with little room for my terminal in my display. Recently I started using fixed values for winopts properties height and width instead of decimal (percentages) so I would have a more consistent experience. But I noticed on small sizes the width take up the full space and on those cases I'd prefer to have some padding.

I noticed that the are max_width and max_height variables used in the code here:

fzf-lua/lua/fzf-lua/win.lua

Line 470 in 758173f

local max_width = vim.o.columns - 2

Both variable use - 2 at the end accounting for the borders or window frames I assume. I was wondering if this padding could be configurable via an option.

When using percentages in width and height the dimensions can differ a lot from one display to another, from one window size to another. When using fixed values sometimes it can be presented as full screen if the window is small enough. The ideal solution would be to have like a css style kind of a width, max_width and min_width then also the same 3 for height but I understand that it would add a lot options for something that probably doesn't need that much granularity. So with the current state I see this - 2 could be easily configurable as a padding option, could be 1 for all or a pair of vertical_padding (or padding_y) to be used for max_height and horizontal_padding (or padding_x) to be used for max_width.

I would very much appreciate your feedback.

[ibhagwan]

Due to legacy the name doesn’t necessarily imply, but winopts.split can specify a function that would return a new window (using nvim_open_win in your case) and fzf-lua will run in it, maybe that’s best for your use case as you have full control over the window? IMHO it’s better than yet another obscure config option nobody knows exists and why it’s there to begin with many edge cases:

fzf-lua/lua/fzf-lua/win.lua

Lines 1035 to 1040 in 758173f

	if self.winopts.split then
	if type(self.winopts.split) == "function" then
	local curwin = vim.api.nvim_get_current_win()
	self.winopts.split()
	assert(curwin ~= vim.api.nvim_get_current_win(), "split function should return a new win")
	else

If this has issues we can tackle these as I’m not sure how many users ever used split as a function, it’s mostly used as a vim command, e.g. belowright new or tabnew.

[carloscalla]

I just realized, if I'm not mistaken, that the opts can also be a function that returns a table with the values, am I right? in that case I can just set my keymap that triggers the picker and make it trigger with the options as a function which calculates width or height depending on vim.o.lines and vim.o.columns, I can do some min/max width logic there and get what I want, is that right? in that case I can do that and take control of it, the function would be evaluated every time I trigger my mapping so if I resize the window it would still get the lates values for lines and columns I believe.

I got the idea from this issue: #793
While reading the wiki here: https://github.com/ibhagwan/fzf-lua/wiki#automatic-sizing-of-heightwidth-of-vimuiselect

    {
      '<leader>ff',
      function()
        require('fzf-lua').files(function
          -- logic to get the desired width or height goes here
          -- return winopts = { my desired values }
        )
      end,
      desc = '[f]ind [f]iles',
    },

@ibhagwan let me know if that makes sense.

[ibhagwan]

@ibhagwan let me know if that makes sense.

@carloscalla, correct.