Winops Split command breaks or is incorrect sometimes

[asmodeus812]

Info

• Operating System: WSL
• Shell: zsh
• Terminal: none (neovide)
• nvim --version: 0.9.1
• fzf --version: 0.39

    vim.api.nvim_create_autocmd({ "VimEnter", "VimResized" }, {
        pattern = "*",
        callback = function()
            vim.g._win_viewport_size = (vim.o.lines - 2 - vim.o.cmdheight)
        end
    })

local generic_cmd = "belowright new | wincmd J | execute %s" -- split at the very bottom of window stack
local preview_cmd = string.format(generic_cmd, "'resize ' . float2nr(ceil(g:_win_viewport_size * 0.50))")
local default_cmd = string.format(generic_cmd, "'resize ' . float2nr(ceil(g:_win_viewport_size * 0.25))")

    fzf_lua.setup(vim.tbl_deep_extend("force", {
        winopts = {
            split = default_cmd,
            height = 0.85,
            width = 0.85,
            row = 0.35,
            col = 0.35,
            preview = {
                delay = 100,
                title = true,
                wrap = "nowrap",
                hidden = "hidden",
                border = "border",
                default = "builtin",
                layout = "vertical",
                vertical = "up:56%",
                horizontal = "right:56%",
                title_align = "center",
            },
        },
        grep = {
            winopts = {
                split = preview_cmd,
                preview = {
                    hidden = "nohidden",
                },
            },
        },
    }, config._config or {}))

Description

The issue started to happen recently, what i see is that when i rotate between grep pickers and any other pickers, where the split resize is supposed to be for grep - bigger, to allow for more space for the preview, and smaller used only for list type pickers (anything else but grep pickers), i see that when you open / close the grep picker a few times, then open list type pickers (any other basically) the rest of the pickers start also opening with the same split command / size (.50 scale) instead of the smaller one (with .25 scale). I have bisected the commits from the current master, and the start of july, and have found the commit after which the issue is occurring here - b62f793. After this commit (including) the issue is reproducible, looking at it actually might make sense, it has modification on the way the config properties are copied around, maybe somehow the grep properties have overridden the default ones in some flow.

On another note, It would be in general great if fzf provided that capability, of rendering the pickers as a pane instead of only floating window, out of the box, might let you remove the need of the split command, and just have something more integrated in the picker itself. I personally don't like the floating window option that is why i am opting to use split pane instead.

[ibhagwan]

maybe somehow the grep properties have overridden the default ones in some flow.

This seems like the right direction, if you have exact replication steps would be great, I.e. open grep first, then files, then anything else, etc.

On another note, It would be in general great if fzf provided that capability, of rendering the pickers as a pane instead of only floating window, out of the box, might let you remove the need of the split command, and just have something more integrated in the picker itself. I personally don't like the floating window option that is why i am opting to use split pane instead.

Not sure I understand what you mean by this, fzf is a binary that runs in the terminal, it can only exist inside neovim terminal buffer, maybe you meant fzf-lua? In that case I’m also unsure what you mean as split is exactly that, a pane, not a floating window (although the builtin previewer floats on top).

If you didn’t try yet, might be worth trying opening fzf-tmux in a tmux split? See #225 (comment)

[asmodeus812]

Okay so for the replication steps, it is not always consistent, but i noticed that if i open / close the grep picker a few times which has a preview, then open close a few other pickers which do not have a preview window, the non-preview pickers will show up with the wrong height (and it stays like that for those types of pickers)

Yes i mean fzf lua, not the binary, i don't think we would ever discuss the binary in this context it makes no sense, so i assumed it is clear what i am talking about. Anyhow, split at the moment is a bit janky, what i was trying to suggest is have concrete config properties which control the 'split' more tightly, so it can be more predictable, and more asumptions can be made by the plugin on how to create a pane, similarly to how the floating window config works at the moment, we have a bunch of properties for configuring the floating window, we don't create it and pass it down to fzf lua to use (a crude example, but the split command does seem like a wonky solution, suffering from being too generic of a solution, as if we don't know what a user would do with the pane, there are finite states for this pane layout where it make sense - e.g a horizontal split which is at top or bottom).

Fzf-tmux seems to be a floating popup, which is not what i am going for here. My goal is quickfix like positioning in case it is not clear.

[ibhagwan]

Yes i mean fzf lua, not the binary, i don't think we would ever discuss the binary in this context it makes no sense, so i assumed it is clear what i am talking about. Anyhow, split at the moment is a bit janky, what i was trying to suggest is have concrete config properties which control the 'split' more tightly, so it can be more predictable, and more asumptions can be made by the plugin on how to create a pane, similarly to how the floating window config works at the moment, we have a bunch of properties for configuring the floating window, we don't create it and pass it down to fzf lua to use (a crude example, but the split command does seem like a wonky solution, suffering from being too generic of a solution, as if we don't know what a user would do with the pane, there are finite states for this pane layout where it make sense - e.g a horizontal split which is at top or bottom).

It is wonky, but it works and uses neovim mechanisms to do so, I agree that having a dedicated config and code routes would be better but given the split functionality isn’t widely used vs the amount of refactor work this would require this isn’t something I’m planning on doing ATM (I’d welcome a PR though).

Fzf-tmux seems to be a floating popup, which is not what i am going for here. My goal is quickfix like positioning in case it is not clear.

Fzf tmux in a popup is the default setting but it can also open in a tmux pane (bottom, right, etc), in fact, fzf-tmux supported panes before it added popup support, see:

[asmodeus812]

I see, but i am not using tmux, would like to stick to vim panes.

[asmodeus812]

@ibhagwan after some investigation it might be due to eadirection, seems like it. The resize from the cmd is sometimes evaluated after the eadirection takes effect, sometimes before, and vim auto resizes the window. Not sure exactly still looking at it.

[ibhagwan]

@ibhagwan after some investigation it might be due to eadirection, seems like it. The resize from the cmd is sometimes evaluated after the eadirection takes effect, sometimes before, and vim auto resizes the window. Not sure exactly still looking at it.

Thanks for the update @asmodeus812! Let me know what your findings.

[asmodeus812]

Seems like if you have equalalways and eadirection=both, then vim would sometimes, manage to resize the windows after the custom exec resize command, i played around with the same command outside fzf context, and it looks like that it's somewhat random, sometimes the resize will take effect correctly post vim doing the equal always auto resize, sometimes auto resize will always be triggered last and override the custom resize. It works more consistently if you schedule wrap the resize, due to the nature of schedule, executing later in the loop, but anyhow i just set eadirection=hor, which causes vim to auto resize window widths only, in my case it works fine.

[ibhagwan]

Thanks for the update @asmodeus812!