Pasting via the right-click menu inserts junk about nvimdots HOT 21 CLOSED

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

from nvimdots.

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 🤣

from nvimdots.

ys, the bulit-in register in nvim

sorry! typo lol

from nvimdots.

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

from nvimdots.

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

from nvimdots.

So quickly like a bat out of hell, Hahaha.

from nvimdots.

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.

from nvimdots.

Can't repro for me.

from nvimdots.

Using copy by your right key.

from nvimdots.

After I clicked copy.

from nvimdots.

Really can't repro

from nvimdots.

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

from nvimdots.

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

from nvimdots.

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?

from nvimdots.

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.

from nvimdots.

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.

from nvimdots.

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

from nvimdots.

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

from nvimdots.

Should be fixed by dstein64/nvim-scrollview@30ca6e1.

from nvimdots.

@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!

from nvimdots.

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!

from nvimdots.