[BUG] Every first screenshot fails with "node code selected"

[willdavidow]

Just installed the plugin and everything works fine for the most part, but it seems the first attempt always fails when trying to generate screenshots to both the clipboard or the save path.

Steps to reproduce

Open nvim and any file Select code and attempt to generate screenshot

Result

no code is selected

Expected

Screenshot generated to either clipboard or save path

When I de-select and re-select the exact code, in the exact same way, everything works fine.. it's just that first attempt that doesn't work.

https://github.com/mistricky/codesnap.nvim/assets/763985/8ec61a14-5231-47e9-b388-a414ba599033

[mistricky]

Hi @willdavidow, thx for this issue reporting, that's interesting bug but I can't reproduce on my machine.

but it seems the first attempt always fails when trying to generate screenshots to both the clipboard or the save path.

The "first attempt" refer to the first screenshot taken after first CodeSnap was installed or the first screenshot taken after opening nvim every time?

[willdavidow]

The "first attempt" refer to the first screenshot taken after first CodeSnap was installed or the first screenshot taken after opening nvim every time?

It's every time after closing and reopening nvim.

[mistricky]

What version of your Neovim? If you enter command instead of use hotkey, did it works?

[DrummyFloyd]

i have the same behaviour upon the couple of first time , when i opend nvim ( LAZYVIM config here)

with command line it work like a charm

return {
  {
    "mistricky/codesnap.nvim",
    build = "make build_generator",
    keys = {
      { "<leader>cs", "<cmd>CodeSnap<cr>", mode = "x", desc = "Save selected code snapshot into clipboard" },
      { "<leader>cS", "<cmd>CodeSnapSave<cr>", mode = "x", desc = "Save selected code snapshot in ~/Pictures/" },
    },
    lazy = true, <= same behaviour with true or false
    opts = {
      mac_window_bar = false,
      save_path = "~/Pictures/",
      has_breadcrumbs = true,
      bg_theme = "sea",
      watermark = "",
      code_font_family = "FiraCode Nerd Font",
      has_line_number = true,
      show_workspace = false,
    },
  },
}

could be related to Lazy event ??

EDIT: i tried on both stable 9.5 adn nightly for Neovim

[willdavidow]

What version of your Neovim? If you enter command instead of use hotkey, did it works?

I'm running nvim nightly: NVIM v0.10.0-dev-3094+ge14e75099-Homebrew - updated a day or two ago.

Running the command directly does work just fine.

[try-to-fly]

I have the same issue, it seems to be a problem with nvim. After starting nvim, the return value of this command is empty. Only after the second execution does the command produce content:

vim.fn.getline("'<", "'>")

Update: It seems that this might not be a bug with nvim after all. I executed the following command directly in the command line, and even on the first launch, it was able to correctly retrieve the selected text content.

'<,'>lua local lines = vim.fn.getline("'<", "'>"); for _, line in ipairs(lines) do print(line) end

[HugoxSaraiva]

I encountered the same issue, but it appears I've found a solution. It seems that the markers '< and >' retain values from the previous visual mode selection. When Neovim is opened, they are set to 0. You can read this for more details.

To resolve this, I simply adjusted my configuration to exit visual mode before calling CodeSnap. Executing the following command: <Esc><cmd>CodeSnap<cr>.

As this bug arises due to the plugin attempting to retrieve the last selection markers rather than the current selection, it could imply that the snapshot result consistently lags by one. However, that requires further verification.

[DrummyFloyd]

I encountered the same issue, but it appears I've found a solution. It seems that the markers '< and >' retain values from the previous visual mode selection. When Neovim is opened, they are set to 0. You can read this for more details.

To resolve this, I simply adjusted my configuration to exit visual mode before calling CodeSnap. Executing the following command: <Esc><cmd>CodeSnap<cr>.

As this bug arises due to the plugin attempting to retrieve the last selection markers rather than the current selection, it could imply that the snapshot result consistently lags by one. However, that requires further verification.

Work as expected, but for me it's kinda of a Workaround , if i check with many other keymap there is no <Esc>