When toggling terminal, cursor jumps from a different buffer to minimap buffer

[John15321]

Check list

• I have read through the README (especially F.A.Q section)
• I have searched through the existing issues

Environment info

• OS
  • Linux
  • Mac OS X

Version info

NVIM v0.5.0
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-11 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az139-878

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/share/nvim"

Run :checkhealth for more info

Question / Problem and steps to reproduce

When opening a terminal with toggleterm, when I close the terminal (the keybinding is ctrl + t for toggling the terminal), the cursor jumps from a previous buffer to the minimap buffer, which is very annoying as I have to move the cursor back between buffers each time I use a terminal in vim.

2021-09-20.00-22-24.mp4

[shaksiper]

I can confirm this happens with several prompts.
Somehow it takes precedence to the last buffer edited.

[John15321]

I can confirm this happens with several prompts. Somehow it takes precedence to the last buffer edited.

Im to dumb of a vim user to know if there even is a way of changing that. Can someone help?

[ZNielsen]

Can you attempt the same test with a regular split window open (via :vsp)? Does the cursor always go to the rightmost window?

[shaksiper]

Can you attempt the same test with a regular split window open (via :vsp)? Does the cursor always go to the rightmost window?

Here is a very simple asciinema of the problem with vsplits
The floating windows has 'nofile' buftype
https://asciinema.org/a/6i9IBwMGmBwGWchaP9cMshvnn

[ZNielsen]

Apologies I was unclear, I meant a split without the minimap. I want to see if the minimap autocmds are grabbing the cursor, or if vim is putting the cursor in the right window when it's finished with the 'nofile' floating window.

[shaksiper]

OH sorry, yes sure
https://asciinema.org/a/MV8bEKnO6PEnkoGfG7Z8NRjo1

[ZNielsen]

Ok, so the minimap is for sure changing the behavior. This probably has to do with the buffer ordering. When you enter a new window, the minimap does stuff, which I think puts it as the 'last used' buffer, so it would be the target when the terminal window exits. We will have to play around with this to confirm.

[John15321]

Nice guys! Tell me if I can help

[ZNielsen]

Is search highlighting enabled in these examples?

[shaksiper]

Yes it is, and it is a little bit weird this time now that I switched it off.
The cursor still went to minimap, but I am not able to move it inside minimap.

[wellcomez]

same issue with
https://github.com/kdheepak/lazygit.nvim
https://github.com/voldikss/vim-floaterm

After plugin's float window is closed , curror will be moved to minimap!!!

[alexeygumirov]

Yes, I can confirm this behavior with vim-floaterm.

[ZNielsen]

Apologies this is taking a long time to track down. I've done some investigating work, but this is a bug that is arising partly from some intrinsic vimisms around buffers/windows. The 'fix' will not really be a fix, but a workaround. I'm still planning to track this down, but it's not as easy as I had hoped, nor have I had as much time to work on it as I have wanted.

[ZNielsen]

The problem I'm seeing is that the floating window is not being reported as a separate window (it doesn't increment wincmd('$')), nor does it trigger the WinClosed autocmd. That might be an issue with toggleterm. In certain situations, plugins need to manually kick off an autocmd event so they play nice. You may want to open a ticket there to see if they are properly sending the correct autocmds when a floating window closes.

Beyond that, the documentation for floating windows is very slim. Floating windows seem to have different behaviors than normal windows, but the behavior is not documented well, if at all.

If you never navigate via the minimap (i.e. the only time your cursor ends up in there, it's a mistake/bug), then you might consider adding a custom autocmd:

function! FloatWindowMinimapHack() abort
    let mmwinnr = bufwinnr('-MINIMAP-')
    if mmwinnr == -1
        return
    endif
    if winnr() == mmwinnr
        " Go to the other window
        execute 'wincmd t'
    endif
endfunction
autocmd WinEnter <buffer> call FloatWindowMinimapHack()

^ Not checked, but something like that might work

[smzm]

Put this code inside your .vimrc :
This gets you back to the previous window every time the cursor goes to the MINIMAP window.

function! FloatWindowMinimapHack() abort
  if winnr() == bufwinnr('-MINIMAP-')
      exe "wincmd w"
  endif
endfunction

autocmd WinEnter * call FloatWindowMinimapHack()

[ulyssesdotcodes]

Haven't done much vim / neovim / lua stuff, but here's my lua attempt at making it go back to the same window you were in before the floating window was opened.

local lastaccessed
vim.api.nvim_create_autocmd({'WinEnter'}, {
  callback = function()
    local minimapname = '-MINIMAP-'
    if string.sub(vim.api.nvim_buf_get_name(0), -string.len(minimapname)) == minimapname then
      local wins = vim.api.nvim_list_wins()
      vim.api.nvim_set_current_win(lastaccessed)
    else
      lastaccessed = vim.api.nvim_eval("win_getid(winnr('#'))")
    end
  end
})

[CnsMaple]

It seems that this issue has been going on for quite some time. In NVIM, I did this:

local pre_window
local float_leave = false
vim.api.nvim_create_autocmd({ "WinEnter", "BufLeave" }, {
    callback = function(event)
        if event.event == "BufLeave" then
            if event.file == '' and event.match == '' then
                float_leave = true
            end
        elseif event.event == "WinEnter" then
            local minimap_name = '-MINIMAP-'
            if string.sub(event.file, -string.len(minimap_name)) == minimap_name and string.sub(event.match, -string.len(minimap_name)) == minimap_name and float_leave then
                vim.api.nvim_set_current_win(pre_window)
            else
                pre_window = vim.fn.win_getid(vim.fn.winnr('#'))
            end
            float_leave = false
        end
    end
})

The main function is to record when the exiting window is a floating window, and if MINIMAP is entered immediately.
This will not lose the function of moving the mouse to minimap, nor will it lose the function of moving a regular window to minimap.

[oliverjhernandez]

Hi, confirm this is still happening, any updates on fixing this?
thanks!

[ZNielsen]

I'm not sure this issue is able to be resolved in a way that is satisfactory to all use cases. If one of the workarounds is not acceptable for your use case, minimap.vim may just be incompatible with floating-window style plugins unless there's some changes to how floating windows are handled (see my previous comment)