Skip to content

bug: Snacks image placement off by one in floating window when using Bufferline.nvim #1557

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
4 tasks done
todmorrison opened this issue Mar 11, 2025 · 5 comments · May be fixed by #1560
Closed
4 tasks done

bug: Snacks image placement off by one in floating window when using Bufferline.nvim #1557

todmorrison opened this issue Mar 11, 2025 · 5 comments · May be fixed by #1560
Labels
bug Something isn't working stale

Comments

@todmorrison
Copy link

todmorrison commented Mar 11, 2025 •
edited
Loading

Did you check docs and existing issues?

  • I have read all the snacks.nvim docs
  • I have updated the plugin to the latest version before submitting this issue
  • I have searched the existing issues of snacks.nvim
  • I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.10.4

Operating system/version

Arch Linux 6.13.5

Describe the bug

I've actually tracked it down to the following code in Snacks.image.placement.render_fallback, I'm just not certain of the correct/best solution:

384 local pos = vim.api.nvim_win_get_position(win)
385 terminal.set_cursor({ pos[1] + 1 + border.top, pos[2] + border.left })

When Bufferline Nvim is enabled, this results in a blank line above the image and the bottom of the image running into the bottom of the floating window frame (i.e. changing it to "pos[1] + 0 + border.top..." corrects the behavior with Bufferline enabled, but then breaks it otherwise).

Image

Steps To Reproduce

I noticed this when running under WezTerm as "placeholders" is false, but can reproduce under kitty by modifying terminal.lua to make it use "render_fallback". Disabling bufferline.nvim also corrects the output, so it's a required factor.

Expected Behavior

Image output should render inside the floating window box regardless of bufferline.nvim being enabled or not.
@todmorrison todmorrison added the bug Something isn't working label Mar 11, 2025
@todmorrison
Copy link
Author

todmorrison commented Mar 11, 2025 •
edited
Loading

One workaround / possible solution. Change the code referenced above to:

    local pos = vim.api.nvim_win_get_position(win)
    if vim.o.showtabline == 2 then
      terminal.set_cursor({ pos[1] + border.top, pos[2] + border.left })
    else
      terminal.set_cursor({ pos[1] + 1 + border.top, pos[2] + border.left })
    end

I'm not sure how to handle the case where showtabline = 1. I haven't found an API for "tabline is shown".

@todmorrison
Copy link
Author

I think this does it:

diff --git a/lua/snacks/image/placement.lua b/lua/snacks/image/placement.lua
index 05c3269..f07af64 100644
--- a/lua/snacks/image/placement.lua
+++ b/lua/snacks/image/placement.lua
@@ -382,7 +382,11 @@ function M:render_fallback(state)
     self:debug("render_fallback", win)
     local border = setmetatable({ opts = vim.api.nvim_win_get_config(win) }, { __index = Snacks.win }):border_size()
     local pos = vim.api.nvim_win_get_position(win)
-    terminal.set_cursor({ pos[1] + 1 + border.top, pos[2] + border.left })
+    if ( vim.o.showtabline == 2 ) or ( vim.o.showtabline == 1 and vim.fn.tabpagenr('$') > 1 ) then
+      terminal.set_cursor({ pos[1] + border.top, pos[2] + border.left })
+    else
+      terminal.set_cursor({ pos[1] + 1 + border.top, pos[2] + border.left })
+    end
     terminal.request({
       a = "p",
       i = self.img.id,

@todmorrison todmorrison mentioned this issue Mar 12, 2025
Open
@todmorrison
Copy link
Author

Submitted PR with the above change

@github-actions GitHub Actions
Copy link
Contributor

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the stale label Apr 12, 2025
@github-actions GitHub Actions
Copy link
Contributor

This issue was closed because it has been stalled for 7 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working stale
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(image): correct off by one issue in render fallback todmorrison/snacks.nvim
1 participant
@todmorrison