Pasting via the right-click menu inserts junk

[yinghaoyu]

Version confirmation

• [X] Confirm

Following prerequisites

• [X] Confirm

Not a user config issue

• [X] Confirm

Neovim version

NVIM v0.10.0

Operating system/version

wsl-ubuntu20.04

Terminal name/version

windows terminal

$TERM environment variable

No response

Branch info

main (Default/Latest)

Fetch Preferences

SSH (use_ssh = true)

How to reproduce the issue

Using your mouse to select the text and copy it, then you can see re("scrollview").handle_mouse("left", true) pasted.

Expected behavior

No extra operation

Actual behavior

No response

Additional information

No response

[ayamir]

Can't repro for me.

https://github.com/ayamir/nvimdots/assets/61657399/74871971-815e-4404-b491-c91a4b7670c5

[yinghaoyu]

Using copy by your right key.

[yinghaoyu]

After I clicked copy.

[ayamir]

Really can't repro

https://github.com/ayamir/nvimdots/assets/61657399/03f4cf00-11d0-4f53-9e82-e1c0b87f4635

[CharlesChiuGit]

i'm not sure if i hit the similar issue, but i also encounter some weird "copy-pasting" when ssh to remote nvim via windows too. maybe wsl is sort of like a remote machine?

the "copy-pasting" issue i mentioned above is that remote nvim will paste whatever in the latest registry when i ssh to it on windows.( but this issue never happened on macos

[Jint-lzxy]

I can reproduce this on my setup. I'll try a minimal setup later to see if the issue is still there.

[Jint-lzxy]

the "copy-pasting" issue i mentioned above is that remote nvim will paste whatever in the latest registry when i ssh to it on windows.( but this issue never happened on macos

@CharlesChiuGit What do u mean by the "latest registry"? r u referring to the * register?

[CharlesChiuGit]

ys, the bulit-in register in nvim

sorry! typo lol

[yinghaoyu]

I can reproduce this on my setup. I'll try a minimal setup later to see if the issue is still there.

Native nvim does not have this problem.

[Jint-lzxy]

I think I've tracked down the cause. @yinghaoyu Can u please confirm if the following minimal init.lua causes this issue?

local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
    vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system({
        "git",
        "clone",
        "--filter=blob:none",
        "--single-branch",
        "https://github.com/folke/lazy.nvim.git",
        lazypath,
    })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
require("lazy").setup({ "dstein64/nvim-scrollview" }, {
    root = root .. "/plugins",
})

-- add anything else here
vim.g.mapleader = " "
vim.api.nvim_set_keymap("n", "<leader>r", "<Cmd>noh<CR>", {})

Use nvim -u init.lua <file> to test this config with the file where you found the issue.

[Jint-lzxy]

ys, the bulit-in register in nvim

@CharlesChiuGit Nah u might wanna switch ur clipboard provider for remote sessions as Windows Terminal really sucks with escape codes lol

[CharlesChiuGit]

as Windows Terminal really sucks with escape codes lol

i used wezterm on windows and encountered this issue lol my "auto-pasting" issue won't happen when i connect to remote machine and use nvim XXX --clean

[Jint-lzxy]

i used wezterm on windows and encountered this issue lol

Hmm I think detailed help logs could be super helpful here. It can be caused by just about anything in our config :( I figured out what's going on here by checking the logs and saw that r (with a space) was mistakenly processed as user input. Afterwards the entire scrollview stuff ended up getting entered as if the user typed it themselves lol

[Jint-lzxy]

I'm gonna report this upstream first lol as I don't think this is an issue with our config.

[Jint-lzxy]

Should be fixed by https://github.com/dstein64/nvim-scrollview/commit/30ca6e18265928eb4ea7402346b4dfddbd8ce41e.

[yinghaoyu]

So quickly like a bat out of hell, Hahaha.

[CharlesChiuGit]

@Jint-lzxy

I figured out what's going on here by checking the logs and saw that r (with a space) was mistakenly processed as user input

could u give me some tips on finding the related log files or how to locate the user input? tks in advanced!

[Jint-lzxy]

could u give me some tips on finding the related log files or how to locate the user input? tks in advanced!

Sure! Generally, the pattern is:

nvim -V[log-level][log-file] [...]

where log-level can be one of the following:

0   -- don't display any messages
1   -- display when viminfo file is read or written
2   -- display sourced files
5   -- display every searched tag-file
8   -- display files that trigger autocommands
9   -- display every triggered autocommand
12  -- display every executed function
13  -- report every thrown, caught, finished, or discarded exception
14  -- display anything pending in a :finally clause
15  -- display every executed ex-command

I would recommend 15 anyway as changes to the register(s) are only recorded at this level and beyond. For example, the following command would store the logs in log.txt under the current directory with log level 10:

nvim -V10log.txt [...]

But locating the exact spot in the log file where the error occurred is much trickier lol my approach for getting an approximation is by:

1. Clearing the log file just before u r about to do something buggy. On BSD-flavored systems, u could do:

   truncate -c -s 0 [log-file]

2. Try to determine the approximate location by searching for the plugin's name, the provider's name, or the name of the component that handles this type of operation. For instance, I located the exact position of this issue in the log by searching for clipboard.vim, as this is where clipboard handling is processed.
3. Now search for the name of the VimL function call that is most likely used to handle this issue (since those vim.fn.* calls are essentially logged as VimL statements). u can look it up in the manual by searching for something like register in :h functions-list.
4. If that doesn't help either, then read through the logs! u'll definitely find something useful, as it usually doesn't span a very large space. For sourced Lua files, search for them on Google if necessary to check exactly which line of Lua code is being executed.

Now that u probably have some information about the issue, go ahead and use a minimal config to test it! Hope this helps lol

[CharlesChiuGit]

i think there might be something wrong with my terminal/shell/ssh setting. When i use some ssh manager tools like termius, none of above "auto-pasting" issue happened.( and somehow it even feels snappier comparing to bare ssh on windows!) i'll try to lacate what could cause the issue on my windows machine, since the log file looks perfectly normal when applying your suggestions. tks for your help! @Jint-lzxy , at least i can narrow the issue to my windows env lol 🤣

[CharlesChiuGit]

well... i sorta avoid above issue... sorta... lol i found out that the "auto-pasting" happened while ssh to remote machine via "pwsh/windows powershell/cmd", but no on "git-bash". so i basically just switch to "git-bash" as my default shell on wezterm and other terminals on windows. looool

---

while solving this issue, i also found out an interesting thing, which is to use zsh nativly on windows w/o installing any extra things! well, if u install git first lol here's the link on how to setup zsh on windows.

[Jint-lzxy]

When i use some ssh manager tools like termius, none of above "auto-pasting" issue happened.( and somehow it even feels snappier comparing to bare ssh on windows!)

Nah I really think this is related to how escape sequences are handled on Windows lol As long as the same set of APIs is used, the result should be the same regardless of the terminal. Check out this KB Article.

i'll try to lacate what could cause the issue on my windows machine, since the log file looks perfectly normal when applying your suggestions.

... and be sure to report back here if u find something worth sharing!

i found out that the "auto-pasting" happened while ssh to remote machine via "pwsh/windows powershell/cmd", but not on "git-bash".

Hmm was it bc of some environment thingy? This really sounds like a mismatch between the TERM environment variable and the database lol

btw, u could also check out this SO answer that gives a concise overview of the shells on Windows. Along those lines, I also think installing a UNIX layer (at least a POSIX-compliant one) on Windows is extremely important as it really makes development a lot easier lmao

while solving this issue, i also found out an interesting thing, which is to use zsh nativly on windows w/o install any extra things! well, if u install git first lol

lol this sounds so coooooool!