Skip to content
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.

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

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

Open
willdavidow opened this issue May 9, 2024 · 18 comments
Open

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

willdavidow opened this issue May 9, 2024 · 18 comments
Labels
bug Something isn't working

Comments

@willdavidow
Copy link

willdavidow commented May 9, 2024

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.

Screen.Recording.2024-05-09.at.9.20.52.AM.mov
@mistricky
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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

@DrummyFloyd
Copy link

DrummyFloyd commented May 15, 2024

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
Copy link
Author

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.

@HugoxSaraiva
Copy link

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
Copy link

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>

@mistricky mistricky added the bug Something isn't working label Jul 4, 2024
@marcinjahn
Copy link

marcinjahn commented Jul 27, 2024

I guess the issue I'm having is related.

My config (LazyVim):

return {
  "mistricky/codesnap.nvim",
  build = "make",
  opts = {
    has_breadcrumbs = true,
    has_line_number = true,
    bg_color = "#212121",
    bg_padding = 0,
    watermark = "",
    mac_window_bar = false,
  },
  keys = {
    { "<leader>cp", "<cmd>CodeSnap<cr>", mode = "x", desc = "Snap selected code into clipboard" },
    { "<leader>cP", "<cmd>CodeSnapHighlight<cr>", mode = "x", desc = "Snap and highlight code into clipboard" },
  },
}

When I select some class manually (SHIFT-V and jjj), and use the keymap (<leader>cp), I get proper result:

image

However, when I select that class using vac keys (it uses treesitter to highlight "outside the class"), the keymap (<leader>cp) results in:

image

Basically, it snaps just the line where my cursor was when I executed vac.

The same scenario works totally fine when invoking the :CodeSnap command

@HugoxSaraiva
Copy link

Hi @marcinjahn,

Have you tried the workaround I've described? This seems like the lag by one I mentioned.
I guess the scenario works when invoking the :CodeSnap command because you have to enter command mode to invoke it.
The selection used on :CodeSnap is updated when you exit visual mode to enter command mode, but that does not occur when you use <leader>cp without the <Esc> workaround.

@Rallanvila
Copy link

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.

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.

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.

My codesnap.lua file

return {
  "mistricky/codesnap.nvim",
  build = "make build_generator",
  keys = {
    { "<leader>cc", "<Esc><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" },
  },
  opts = {
    save_path = "~/Pictures",
    has_breadcrumbs = true,
    show_workspace = true,
    has_line_numbers = true,
    bg_theme = "bamboo",
  },
}

I tried this fix however I continue to get No executable codelens found at current line when I highlight the code and <leader>cc

@DrummyFloyd
Copy link

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.

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.

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.

My codesnap.lua file

return {
  "mistricky/codesnap.nvim",
  build = "make build_generator",
  keys = {
    { "<leader>cc", "<Esc><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" },
  },
  opts = {
    save_path = "~/Pictures",
    has_breadcrumbs = true,
    show_workspace = true,
    has_line_numbers = true,
    bg_theme = "bamboo",
  },
}

I tried this fix however I continue to get No executable codelens found at current line when I highlight the code and <leader>cc

it's because u did not override the keymaps from lazyVim, your issue is not related to CodeSnap but with your keysmaps

image

@Rallanvila
Copy link

I don't understand. I have nothing bound to <leader>cc in my keymaps and it's bound to run codelens

CleanShot 2024-09-19 at 11 56 27

I copied the install instructions, which enabled these configs, as I don't have anything else configured to use those bindings.

@willdavidow
Copy link
Author

I don't understand. I have nothing bound to <leader>cc in my keymaps and it's bound to run codelens

CleanShot 2024-09-19 at 11 56 27

I copied the install instructions, which enabled these configs, as I don't have anything else configured to use those bindings.

start neovim with nvim -V1 and then run verbose vmap <leader>cc to see where that keybinding is set in your config

@Rallanvila
Copy link

Rallanvila commented Sep 19, 2024

@willdavidow
CleanShot 2024-09-19 at 12 54 19

So it looks like it's mapped correctly, however, when I try to use it, I get No executable codelens found at current line

@willdavidow
Copy link
Author

willdavidow commented Sep 19, 2024

@Rallanvila you might need to set it for x mode.

if it helps at all, here's my config:

return {
  "mistricky/codesnap.nvim",
  build = "make build_generator",
  -- opts = {
  -- },
  config = function()
    require("codesnap").setup {
      save_path = "~/Desktop",
      file_extension = "png",
      has_breadcrumbs = true,
      has_line_number = true,
      watermark = "",
      bg_color = "#535c68",
      bg_padding = 0,
      code_font_family = "JetBrainsMonoNL Nerd Font",
      watermark_font_family = "JetBrainsMonoNL Nerd Font",
      -- prefix = "📸 ",
      -- default options
      -- prefix = "📸 ",
      -- prompt = "Enter a name for the snapshot: ",
      -- file_path = "~/Desktop/",
      -- file_name = nil,
      -- file_extension = "png",
      -- highlight = "Visual",
      -- highlight_group = "Visual",
      -- highlight_file = nil,
      -- highlight_format = "png",
      -- highlight_options = {},
      -- silent = false,
      -- callback = nil,
    }
    local wk = require "which-key"
    wk.add {
      { "<leader>cc", "<cmd>CodeSnap<cr>", desc = "Save selected code snapshot into clipboard", mode = { "v", "x" } },
      { "<leader>cs", "<cmd>CodeSnapSave<cr>", desc = "Save selected code snapshot to ~/Desktop", mode = { "v", "x" } },
    }
  end,
}

@Rallanvila
Copy link

@willdavidow, thanks for the config, I don't know what's going on. I c/p'd it in and you can see the commented code above from what I tried to run previously as well.

CleanShot 2024-09-19 at 17 17 23

@willdavidow
Copy link
Author

@Rallanvila It looks like the key bindings here are not overriding the code lens setting. I don't use LazyVim, just the Lazy package installer - so I'm not sure if there's a special way to override keybindings.

It looks to me like the lazily loaded language server key bindings for whatever file you're in are getting set after this plugin so you'd need a way to override that, or an easier approach would be to just pick an unused key binding/combination.

@Rallanvila
Copy link

image

I mapped it to something else and it worked. I couldn't figure out how to override the mappings for my life. I appreciate you @willdavidow 🙏🏼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants