image.nvim icon indicating copy to clipboard operation
image.nvim copied to clipboard

[Bug]: Misplacement of pictures

Open xuwei152 opened this issue 1 year ago ‱ 11 comments

The position of pictures is not corrected, shown as pic below Clip_2024-05-29_16-42-17

The plugin is install with lazy.nvim with the configuration shown below

{
    "3rd/image.nvim",
    ft = { "markdown" },
    dependencies = {
      {
        "nvim-treesitter/nvim-treesitter",
        build = ":TSUpdate",
        config = function()
          require("nvim-treesitter.configs").setup({
            ensure_installed = { "markdown" },
            highlight = { enable = true },
          })
        end,
      },
    },
    config = function()
      require("image").setup({
        backend = "kitty",
        integrations = {
          markdown = {
            enabled = true,
            clear_in_insert_mode = true,
            download_remote_images = true,
            only_render_image_at_cursor = true,
            filetypes = { "markdown", "vimwiki" }, -- markdown extensions (ie. quarto) can go here
          },
          neorg = {
            enabled = true,
            clear_in_insert_mode = false,
            download_remote_images = true,
            only_render_image_at_cursor = false,
            filetypes = { "norg" },
          },
        },
        max_width = nil,
        max_height = nil,
        max_width_window_percentage = nil,
        max_height_window_percentage = 50,
        kitty_method = "normal",
      })
    end
  },

Environment:

  • OS: Ubuntu 22.04.4 LTS on Windows 10 x86_64
  • tmux next-3.4 in kitty 0.34.1
  • NVIM v0.10.0
  • commit 645f997d171ea3d2505986a0519755600a26f02f

xuwei152 avatar May 29 '24 08:05 xuwei152

Hey, do you use any kind of tab bar / breadcrumbs thing?

3rd avatar Jun 02 '24 13:06 3rd

Yes, I have installed lualine.nvim. Other loaded plugins are listed as follows:


  Total: 105 plugins

  Loaded (80)
    ● alpha-nvim 15.92ms îȘ† VimEnter
    ● bigfile.nvim 52.18ms îȘ† BufReadPre
    ● bufferline.nvim 25.05ms îȘ† User FileOpened
    ● cmp-buffer 21.45ms  nvim-cmp
    ● cmp-bufname 29.38ms îȘ† VeryLazy
    ● cmp-cmdline 23.37ms  nvim-cmp
    ● cmp-dictionary 21.95ms îȘ† VeryLazy
    ● cmp-fuzzy-path 174.08ms îȘ† VeryLazy
    ● cmp-git 23.76ms îȘ† InsertEnter
    ● cmp-latex-symbols 36.26ms  markdown
    ● cmp-nvim-lsp 17.28ms  nvim-cmp
    ● cmp-omni 16.59ms îȘ† InsertEnter
    ● cmp-path 19.76ms  nvim-cmp
    ● cmp_luasnip 33.53ms  nvim-cmp
    ● coc.nvim 80.99ms îȘ† InsertEnter
    ● Comment.nvim 16.46ms îȘ† User FileOpened
    ● fittencode.nvim 61.95ms îȘ† InsertEnter
    ● friendly-snippets 22.39ms  LuaSnip
    ● fuzzy.nvim 1.73ms  cmp-fuzzy-path
    ● fzf 6.24ms  fzf.vim
    ● fzf.vim 13.08ms  start
    ● gitsigns.nvim 22.86ms îȘ† User FileOpened
    ● hop.nvim 25.39ms  HopChar1
    ● http.nvim 11.71ms îȘ† VeryLazy
    ● image.nvim 174.54ms  markdown
    ● indent-blankline.nvim 13.3ms îȘ† User FileOpened
    ● latex-unicoder.vim 1.48ms  markdown
    ● latex.nvim 0.62ms  markdown
    ● lazy.nvim 34.75ms ï„Ą init.lua
    ● leap.nvim 24.25ms îȘ† VeryLazy
    ● lspkind.nvim 4.28ms  start
    ● ltex-client.nvim 14.39ms îȘ† VeryLazy
    ● lualine.nvim 69.13ms îȘ† VimEnter
    ● LuaSnip 171.2ms ó°ą± luasnip.loaders.from_lua  LuaSnip
    ● mason-lspconfig.nvim 28.7ms  nvim-lspconfig
    ● mason.nvim 15.64ms  mason-lspconfig.nvim
    ● mkdnflow.nvim 24.25ms  markdown
    ● nlsp-settings.nvim 1.32ms  nvim-lspconfig
    ● none-ls.nvim 1.07ms ó°ą± null-ls.rpc  none-ls.nvim
    ● nvim-autopairs 25.8ms îȘ† InsertEnter
    ● nvim-cmp 143.54ms  cmp-fuzzy-path
    ● nvim-lastplace 12.53ms îȘ† BufRead
    ● nvim-lspconfig 34.92ms  nvim-texis
    ● nvim-markdown 7.33ms  markdown
    ● nvim-navic 10.42ms îȘ† User FileOpened
    ● nvim-neoclip.lua 22.76ms îȘ† VeryLazy
    ● nvim-texis 41.58ms  start
    ● nvim-treesitter 47.54ms  bigfile.nvim
    ● nvim-treesitter-context 63.22ms îȘ† VeryLazy
    ● nvim-ts-context-commentstring 11.58ms ó°ą± ts_context_commentstring.integrations.comment_nvim ï„Ą /home/xuwei/Trash/lunarvim/lvim/lua/lvim/core/comment.lua
    ● nvim-ufo 22.12ms îȘ† VeryLazy
    ● nvim-web-devicons 1.6ms ó°ą± nvim-web-devicons ï„Ą /home/xuwei/Trash/lunarvim/lvim/lua/lvim/core/breadcrumbs.lua
    ● nvim-window 16.98ms îȘ† VeryLazy
    ● nvim_context_vt 3.29ms îȘ† VeryLazy
    ● onedarker.nvim 60.71ms  start
    ● plenary.nvim 1.76ms ó°ą± plenary.path  telescope.nvim
    ● promise-async 10.98ms  nvim-ufo
    ● rainbow-delimiters.nvim 24.92ms  start
    ● snippet-converter.nvim 42.66ms îȘ† VeryLazy
    ● spelunker.vim 18.91ms îȘ† VeryLazy
    ● tabular 38.35ms îȘ† InsertEnter
    ● telescope-bibtex.nvim 41.56ms îȘ† VeryLazy
    ● telescope-fzf-native.nvim 11.71ms  telescope.nvim
    ● telescope-luasnip.nvim 201.28ms îȘ† VeryLazy
    ● telescope.nvim 118.11ms ó°ą± telescope  telescope-luasnip.nvim
    ● todo-comments.nvim 25.2ms îȘ† VeryLazy
    ● trouble.nvim 1.7ms ó°ą± trouble ï„Ą lua
    ● vim-conceal 0.76ms îȘ† VeryLazy
    ● vim-cursorword 29.55ms îȘ† VeryLazy
    ● vim-custom-surround 2.14ms îȘ† VeryLazy
    ● vim-devicons 4.91ms îȘ† VeryLazy
    ● vim-diminactive 2.89ms îȘ† VeryLazy
    ● vim-easymotion 5.4ms îȘ† InsertEnter
    ● vim-illuminate 15.81ms îȘ† User FileOpened
    ● vim-surround 2.22ms îȘ† InsertEnter
    ● vim-tmux-navigator 1.96ms îȘ† VeryLazy
    ● vim-zoom 3.04ms îȘ† VeryLazy
    ● vimtex 7.07ms  start
    ● which-key.nvim 55.8ms îȘ† VeryLazy
    ● zoomwintab.vim 2.11ms îȘ† VeryLazy

xuwei152 avatar Jun 02 '24 14:06 xuwei152

Maybe an option to give the image an initial global rendering offset would be a good idea it just needs an offset of 2 columns down to be "corrected" assuming because of the barbar + breadcrums extension, also The autocmd of the image render at buffer change doesn't work well for me as I have to close and reopen nvim to have the images refreshed in md files, so maybe exposing a function to refresh all images on scene'd useful as well,

BTW It maybe because I don't have sufficient knowledge in lua but how do to access each individual image rendered in markdown? (in what array / through what method etc...

MikeLemo1 avatar Jun 07 '24 11:06 MikeLemo1

Yes, will add a global offset option, will also try to monitor when something like barbar mounts, the issue if I remember was that it's not there when we check for it.

The integration (https://github.com/3rd/image.nvim/blob/master/lua/image/integrations/markdown.lua) extracts the and creates images, you can use .get_images() to query them: https://github.com/3rd/image.nvim/blob/a2a0849e0b3dbed90f9283603cedb683bda5d4d1/lua/image/init.lua#L411

3rd avatar Jun 08 '24 11:06 3rd

BTW a quick and dirty way to offset the image 2 column down is to go to "~/.local/share/nvim/lazy/image.nvim/lua/image/utils/offsets.lua" and change line 22 from: local y = 0 to local y = 2

Altough is mostly corrected the problem it requires a new line of spacing in order not to obstruct the content belowe it which is covers half a column below it more than then size of the picture after the 2 column offset but now it's workable 1 extra column that's also serve as spacing is acceptable for now, Now displaying svg's I noticed the rendering doesn't take into account the opacity value for some reason... any quick fix for that? or that requires diving into the image drivers bit?

MikeLemo1 avatar Jun 10 '24 12:06 MikeLemo1

It is quite weird that some of the pictures are placed properly. Clip_2024-06-10_21-53-27

Therefore, the modification of the offset cannot fix the problem.

xuwei152 avatar Jun 10 '24 13:06 xuwei152

It is quite weird that some of the pictures are placed properly. Clip_2024-06-10_21-53-27

Therefore, the modification of the offset cannot fix the problem.

Are there specific image files you have that display properly?

MikeLemo1 avatar Jun 10 '24 15:06 MikeLemo1

Yes, some images are displayed properly. One of them is shown as below.

It is quite weird that some of the pictures are placed properly. Clip_2024-06-10_21-53-27

Therefore, the modification of the offset cannot fix the problem.

I have moved the image that are displayed improperly to other places and then it is placed correctly. I guess the problem is related to text surrounding the image.

xuwei152 avatar Jun 10 '24 15:06 xuwei152

BTW a quick and dirty way to offset the image 2 column down is to go to "~/.local/share/nvim/lazy/image.nvim/lua/image/utils/offsets.lua" and change line 22 from: local y = 0 to local y = 2

Altough is mostly corrected the problem it requires a new line of spacing in order not to obstruct the content belowe it which is covers half a column below it more than then size of the picture after the 2 column offset but now it's workable 1 extra column that's also serve as spacing is acceptable for now, Now displaying svg's I noticed the rendering doesn't take into account the opacity value for some reason... any quick fix for that? or that requires diving into the image drivers bit?

ImageMagick is the issue for transparency, I'm working on a complete replacement for it.

3rd avatar Jun 10 '24 15:06 3rd

Yes, some images are displayed properly. One of them is shown as below.

It is quite weird that some of the pictures are placed properly. Clip_2024-06-10_21-53-27

Therefore, the modification of the offset cannot fix the problem.

I have moved the image that are displayed improperly to other places and then it is placed correctly. I guess the problem is related to text surrounding the image.

I think in all cases it's caused by tab bar handling, will look into it.

3rd avatar Jun 10 '24 15:06 3rd

I have a similar issue, apparently caused by concealed wrapped lines. The attached markdown file should be a minimal example (you must ensure that the width of the terminal is less than the length of the URLs).

Screenshot 2024-07-05 at 21 41 41

images.md

sudo-burger avatar Jul 05 '24 19:07 sudo-burger

I can confirm that I am having the same issue with wrapped lines. Disabling wrap fixes the images; but of course, disabling wrap in markdown documents is not preferred.

ficd0 avatar Dec 03 '24 23:12 ficd0

I was about to post a new issue, but I'm having the same problem. In the case of urxvt and ueberzugpp, the images render over text unlike in Kitty (which does it the opposite way). This makes it a lot more apparent:

Issue preview

purplebar0 avatar Dec 30 '24 18:12 purplebar0

wrap support has been merged and i have no issues with winbar closing, please re-open if you find any issues

3rd avatar Apr 22 '25 01:04 3rd

Hi, I'm also experiencing this issue! I've tried both Ghostty and Kitty, and I've completely redone my neovim configuration in between my testing attempts (nvchad -> kickstart). The misalignment has been in the same place the entire time.

As you can see, the correct text padding is created to fit the image, however the image is placed one row above and one column to the right of where it should be. I'm not using a tab bar, and when I remove my statusline, it's still in the same place.

-- using Lazy.nvim
{
  '3rd/image.nvim',
  event = 'VeryLazy',
  dependencies = {
    'nvim-treesitter/nvim-treesitter',
  },
  opts = {
    backend = 'kitty',
    integrations = {
      markdown = {
        enabled = true,
        clear_in_insert_mode = false,
        download_remote_images = true,
        only_render_image_at_cursor = false,
        filetypes = { 'markdown', 'quarto', 'vimwiki' },
      },
    },
    max_width = 100,
    max_height = 12,
    max_height_window_percentage = math.huge,
    max_width_window_percentage = math.huge,
    window_overlap_clear_enabled = true,
    window_overlap_clear_ft_ignore = { 'cmp_menu', 'cmp_docs', '' },
    kitty_method = 'normal',
  },
}
  • Arch Linux x86_64 kernel 6.15.3
  • Wayland 1.23.1
  • KDE Plasma 6.4
  • kitty 0.42.1
  • ghostty 1.1.3-arch1
  • Neovim 0.11.2
  • Lua 5.4.8
  • LuaJIT 2.1.1748459687
  • image.nvim commit 4c51d62

Image

OrionOth avatar Jun 24 '25 03:06 OrionOth

Btw, folke in his snacks image feature solved this somehow, it works perfectly with his package

https://github.com/folke/snacks.nvim

goodhumored avatar Jun 24 '25 08:06 goodhumored