ObsidianPasteImg never works.

[Redoxahmii]

🐛 Describe the bug

Whenever using this command it says no image data in the clipboard.

Config

return {
  "epwalsh/obsidian.nvim",
  version = "*",
  lazy = true,
  cmd = "ObsidianQuickSwitch",
  ft = "markdown",
  keys = {
    { "<leader>wW", mode = "n", "<cmd>ObsidianQuickSwitch<cr>", desc = "Obsidian Notes" },
  },

  -- Replace the above line with this if you only want to load obsidian.nvim for markdown files in your vault:
  -- event = {
  --   -- If you want to use the home shortcut '~' here you need to call 'vim.fn.expand'.
  --   -- E.g. "BufReadPre " .. vim.fn.expand "~" .. "/my-vault/**.md"
  --   "BufReadPre path/to/my-vault/**.md",
  --   "BufNewFile path/to/my-vault/**.md",
  -- },
  dependencies = {
    -- Required.
    "nvim-lua/plenary.nvim",
    "hrsh7th/nvim-cmp",
    "nvim-treesitter/nvim-treesitter",
    "3rd/image.nvim",
    -- see below for full list of optional dependencies 👇
  },
  opts = {
    ui = {
      enable = false,
    },
    templates = {
      debug = true,
      folder = "~/Code/Obsidian/Templates",
    },
    daily_notes = {
      folder = "Daily",
      template = "/Daily Notes.md",
    },
    attachments = {
      img_folder = "Images",
    },
    follow_url_func = function(url)
      print("Opening URL: " .. url)
      vim.fn.jobstart({ "xdg-open", url }) -- linux
    end,
    workspaces = {
      {
        name = "personal",
        path = "~/Code/Obsidian/",
      },
    },
    pickers = {
      name = "fzf-lua",
    },
  },
}

Environment

NVIM v0.10.1
Build type: Release
LuaJIT 2.1.1720049189
Run "nvim -V1 -v" for more info
fzf-lua fatal: '_G._fzf_lua_server', '_G._devicons_path' both nil
fzf-lua fatal: '_G._fzf_lua_server', '_G._devicons_path' both nil
Obsidian.nvim v3.9.0 (ae1f76a75c7ce36866e1d9342a8f6f5b9c2caf9b)
Status:
  • buffer directory: nil
  • working directory: /home/redox/Code/React/PrintToPoint
Workspaces:
  ✓ active workspace: Workspace(name='personal', path='/home/redox/Code/Obsidian', root='/home/redox/Code/Obsidian')
Dependencies:
  ✓ plenary.nvim: ec289423a1693aeae6cd0d503bac2856af74edaa
  ✓ nvim-cmp: ae644feb7b67bf1ce4260c231d1d4300b19c6f30
Integrations:
  ✓ picker: nil
  ✓ completion: enabled (nvim-cmp) ✗ refs, ✗ tags, ✗ new
    all sources:
      • nvim_lsp
      • path
      • buffer
      • lazydev
      • luasnip
Tools:
  ✓ rg: ripgrep 14.1.0
Environment:
  • operating system: Linux
Config:
  • notes_subdir: nil%

[NicholasZolton]

What does :! echo $XDG_SESSION_TYPE return?

I had this issue when using Neovide on Ubuntu 24.04 and realized that the above command was outputting "wayland" and not "x11" or "tty'.

To fix this I did sudo apt install wl-clipboard which is the expected clipboard cmdline tool for wayland. Otherwise, the expected is xclip.

(to debug this myself I used print statements in /home/(my_user)/.local/share/nvim/lazy/obsidian.nvim/lua/obsidian/img_paste.lua since I use lazy.nvim)

[Redoxahmii]

It says wayland.
I usually run my kitty terminal as an x11 process but i have also tested it running with wayland and still i get the error and yes i do have wl-clipboard installed.
I have also tested using x-clip when running the terminal as an x11 process and the results are still the same.
It says that there is no image data in clipboard.

[Redoxahmii]

@NicholasZolton
Can you after copying an image send the output of wl-paste --list-types.
Mine seems to be missing any image there but instead shows KDE related such as :

text/uri-list
application/x-kde4-urilist
application/vnd.portal.filetransfer
application/x-kde-source-id 

Reason for asking this is because in the paste_img.lua it seems to be checking for image/png.

[NicholasZolton]

Mine results in the following:

SAVE_TARGETS
TIMESTAMP
MULTIPLE
TARGETS
image/png

Personally, I am using flameshot gui and then doing Ctrl-c to copy the image to the clipboard.

How are you copying the image?

[Redoxahmii]

the output i provided above used copying image from Dolphin file manager.
I have now tested it using Spectacle which is the screenshot utility in KDE.
Now it outputs this :

image/png
x-kde-force-image-copy

Which means it should work but it still prompts me with the same error saying there is no image data in the clipboard which there is now for the matching pattern provided.
Weird.

[Redoxahmii]

The clipboard_is_img function seems to be returning nothing when using vim.notify to see its output.
The get_clip_check_command works fine and actually is using the right command for it tho.

[NicholasZolton]

Only other idea I have is that perhaps your clipboard command is not being recognized in nvim or is failing - maybe the path is different from your shell or there's something weird going on with permissions?

Maybe try checking the output of the clipboard command in:

  for output in assert(io.popen(get_clip_check_command())):lines() do
    content[#content + 1] = output
  end

[Redoxahmii]

That's what i checked first and it outputs nothing.
Seems to output fine if i use bang ! to output from neovim running wl-paste --list-types so should'nt really be an issue with permissions.

[NicholasZolton]

That's quite odd. I know this might seem redundant, but do you mind trying the following in your config?

vim.notify(
  string.format(
    "wl-paste available: %d and xclip available: %d",
    vim.fn.executable "wl-paste",
    vim.fn.executable "xclip"
  )
)

just to see if vim itself can recognize the binaries.

[elianmanzueta]

I am having the same issue, when I run the above code I get wl-paste available: 1 and xclip available: 0. This only happens on my PC running Arch at home, not on my Mac or on WSL (also running Arch) on my workstation.

My session type is showing as wayland.

I am also using KDE Plasma 6 with spectacle, and the output for wl-paste --list-types is:

image/png
x-kde-force-image-copy

Environment:

NVIM v0.10.1
Build type: Release
LuaJIT 2.1.1725453128

fzf-lua fatal: '_G._fzf_lua_server', '_G._devicons_path' both nil
fzf-lua fatal: '_G._fzf_lua_server', '_G._devicons_path' both nil
Obsidian.nvim v3.9.0 (ae1f76a75c7ce36866e1d9342a8f6f5b9c2caf9b)
Status:
  • buffer directory: nil
  • working directory: /home/elian/obsidian
Workspaces:
  ✓ active workspace: Workspace(name='personal', path='/home/elian/obsidian', root='/home/elian/obsidian')
Dependencies:
  ✓ plenary.nvim: ec289423a1693aeae6cd0d503bac2856af74edaa
  ✓ nvim-cmp: ae644feb7b67bf1ce4260c231d1d4300b19c6f30
Integrations:
  ✓ picker: nil
  ✓ completion: enabled (nvim-cmp) ✗ refs, ✗ tags, ✗ new
    all sources:
      • nvim_lsp
      • path
      • buffer
      • snippets
      • lazydev
      • crates
Tools:
  ✓ rg: ripgrep 14.1.1
Environment:
  • operating system: Linux
Config:
  • notes_subdir: nil

[Redoxahmii]

@NicholasZolton The same output as mentioned by @elianmanzueta.
wl-paste available: 1 and xclip available: 0

[NicholasZolton]

I know this is probably overkill, but I'm guessing if you copy something and then run this code you get no output for either command?

local xdg_session = os.getenv "XDG_SESSION_TYPE"
local cmd_output = assert(io.popen "wl-paste --list-types"):lines()
local cmd_output2 = assert(io.popen "xclip -selection clipboard -o -t TARGETS"):lines()
-- concat all the lines into a string for each command
local cmd_output_line = ""
for line in cmd_output do
  cmd_output_line = cmd_output_line .. ";" .. line
end
local cmd_output_line2 = ""
for line in cmd_output2 do
  cmd_output_line2 = cmd_output_line2 .. ";" .. line
end

vim.notify(
  string.format(
    "wl-paste available: %d, xclip available: %d, OS: %s, cmd_output1: %s, cmd_output2: %s",
    vim.fn.executable "wl-paste",
    vim.fn.executable "xclip",
    xdg_session,
    cmd_output_line,
    cmd_output_line2
  )
)

[Redoxahmii]

wl-paste available: 1, xclip available: 0, OS: wayland, cmd_output1: ;image/png;x-kde-force-image-copy, cmd_ou utput2:

Working as it should i'm baffled too at this point lol.
I highly suspected it might have been the KDE clipboard doing something but using bang operators and this does provide with results so that should not be the issue as it is getting the output correctly.

[NicholasZolton]

Yeah at this point I'm really confused lol.

Maybe double check that the recognized OS is correct from the obsidian util?

  local sysname = vim.loop.os_uname().sysname
  local release = vim.loop.os_uname().release:lower()
  vim.notify(string.format("Sysname: %s, Release: %s", sysname, release))

The error is definitely occurring in that function based on your previous comments, and vim is clearly able to get the output using the correct command line utils, so the only thing left would be this code snippet having an error - if this returns a value we would expect I am completely out of ideas.

[Redoxahmii]

works fine lol

Sysname: Linux, Release: 6.10.8-arch1-1

[NicholasZolton]

This might be a big stretch, but are you sure the tests above were run using the same Lua binary that Neovim is using?

For example, if you are using something like Sniprun for the tests could you place the above debug tests at the end of your config and restart Neovim as a whole?

I really have no other ideas related to the code itself so the only thing left is to test the base assumptions I suppose 😐.

[Redoxahmii]

I am using LazyVim which has the folder structure of :
/lua/config/keymaps.lua and a few other files.
I am just putting them there as they get sourced when i quit and open neovim.
As for binaries i don't think there is any possible way for them to be using different only a single binary exists for Neovim.

[NicholasZolton]

That makes sense, I was hoping there was some quirk with how the files were being run, but it seems like that's not the case either. Hopefully someone else can jump in with an idea, the only thing left (in my opinion) is to step through the code line-by-line with nvim-dap.

[mccuna]

I had the same issue on my side. Removing version = "*" from the config and using the latest commit instead of the latest stable version fixed the issue for me.

The latest stable version was released on the 11th of July and since then there have been a couple of commits related to images. I haven't looked into these commits, but most probably the fix is in one of them.

[Redoxahmii]

I did move it to the latest unfortunately still same results.
I'll will look into the commits to see if it provides anything new that might help with debugging,