c-v will insert `:call paste#Paste()<CR>` instead of clipboard if use ale

[NewUserHa]

win10 gvim8

I already found it's ale made this issue to my vim by commenting out other plugins. if I comment out nothing but ale, the c-v work properly.

1.enable ale using vim-plug
2.copy something into clipboard
3(tested again, no need).select something in insert mode by shift + arrows
4.press <C-v>
5.boom, `:call paste#Paste()<CR>` appear instead of clipboard

ale is a nice linter and uses every day so I hope this can be fixed quickly thanks

[w0rp]

Do you see any errors from ALE? Are you running any other plugins when you see this problem? I'm not sure how to reproduce this bug, as I don't see this on Windows myself.

[NewUserHa]

no errors.

the vimrc in gif:

call plug#begin('$VIM/vimfiles/plugged')
Plug 'w0rp/ale'
call plug#end()

source $VIMRUNTIME/vimrc_example.vim
source $VIMRUNTIME/mswin.vim

set diffexpr=MyDiff()
function MyDiff()
  let opt = '-a --binary '
  if &diffopt =~ 'icase' | let opt = opt . '-i ' | endif
  if &diffopt =~ 'iwhite' | let opt = opt . '-b ' | endif
  let arg1 = v:fname_in
  if arg1 =~ ' ' | let arg1 = '"' . arg1 . '"' | endif
  let arg2 = v:fname_new
  if arg2 =~ ' ' | let arg2 = '"' . arg2 . '"' | endif
  let arg3 = v:fname_out
  if arg3 =~ ' ' | let arg3 = '"' . arg3 . '"' | endif
  if $VIMRUNTIME =~ ' '
    if &sh =~ '\<cmd'
      if empty(&shellxquote)
        let l:shxq_sav = ''
        set shellxquote&
      endif
      let cmd = '"' . $VIMRUNTIME . '\diff"'
    else
      let cmd = substitute($VIMRUNTIME, ' ', '" ', '') . '\diff"'
    endif
  else
    let cmd = $VIMRUNTIME . '\diff'
  endif
  silent execute '!' . cmd . ' ' . opt . arg1 . ' ' . arg2 . ' > ' . arg3
  if exists('l:shxq_sav')
    let &shellxquote=l:shxq_sav
  endif
endfunction

[w0rp]

Maybe there's a problem in one of the files you're sourcing. Maybe it's running :call ... without <CR> at the end for a key binding.

[w0rp]

ALE doesn't configure any keybinds itself, so I don't think this problem is caused by ALE.

[NewUserHa]

but only when enable ALE cause this problem, not any other plugins. the rest configure are the default vimrc created by vim after installing it, it's not setted by me

[w0rp]

What's the output of :map <c-v>?

[NewUserHa]

v  <C-V>       & "-c<Esc>:call paste#Paste()<CR>
no <C-V>         "+gP
Press ENTER or type command to continue

[NewUserHa]

can't you reproduce the issue? even on win10 + gvim8?

[w0rp]

I don't see the issue myself. I might try using something closer to your configuration later on Windows 10 and see if I can reproduce it.

[busticated]

i'm seeing this behavior as well - macOS v10.13.4, mac vim v8.0.1633

[w0rp]

Okay, if you have some steps to reproduce it which will work on Linux, let me know. I don't have access to a Mac.

[efournival]

Got the same problem:

• ArchLinux up-to-date and GVIM 8.0.1838
• behave mswin in .vimrc (hence Ctrl+V)
• ale through Pathogen installed

The bug is hard to reproduce and happens occasionally. Everything was working fine before installing ale. Will update here once I have the steps to reproduce. I also confirm the OP's steps are not enough to reproduce.

[w0rp]

Okay, sounds good. Let me know if you can come up with some steps for repeating the bug easily, and I'll see what I can do.

[NewUserHa]

I didn't touch anything about vim and it's plugins except the vimrc was changed as what I posted above. it do seldom paste the right content instead :call paste#Paste()<CR>.

I installed ale via vim-plug

[efournival]

@w0rp I think I managed to reproduce the issue in a reliable way:

• behave mswin in .vimrc
• open a file where linting is enabled
• copy something in the clipboard with Ctrl+C
• on a line where there is a linting error, select something with Shift+Arrows or with the mouse if enabled
• hit Ctrl+V, get :call paste#Paste() inserted instead of the clipboard content

I am able to reproduce it 100% of the time. If you need minimal files and configurations, feel free to ask. Thanks for working on ale.

[w0rp]

Thank you for the explanation. I'll give that a go.

[w0rp]

I don't see the same issue on my machine if I follow those steps. I use the following replacement vimrc file.

set nocompatible
filetype plugin on
behave mswin
:so $VIMRUNTIME/mswin.vim

packloadall

I opened a Python file with some bad syntax and ALE running with /usr/bin/gvim -u test.vim test.py.

I think you'll have more luck if you try and fix the bug yourself, because I can't repeat it.

[efournival]

Well, I'm able to reproduce using your vimrc file and just ale installed... I tested it on a JavaScript ES6 file using standard (sudo npm install -g standard). I can also reproduce on a Go source file using goimports. I'm using GVIM + vim-runtime 8.1.0022 under an up-to-date ArchLinux.

Unfortunately I'm not skilled in VimScript so fixing it by myself would take days. :( Otherwise, I would have already sent a PR.

Can you please try one more time with a Go or JS file using the specified linters? Thanks a lot

[w0rp]

I don't think I'll be able to repeat the bug myself. I've tried a few times. I don't know what might be causing. It might be some weird bug in Vim.

[NewUserHa]

how can I borrow my bug to you(joke

I installed a brand new win10 1803 on a new pc months ago. I installed vim by gvim_8.0.1599_x86.exe and ale via plug-vim also. the bug still there, so it's 100% reproducible. did you try win10 to reproduce? it may be related to OS?

[NewUserHa]

because of this bug, I always have to delete the selected texts before paste anything first then c-v paste it, otherwise triggered it. so sadly

ps. I think without selecting texts, it mostly pastes the right thing, but not 100%. if I remember correctly if the content in clipboard is complex, it may go wrong( not 100% sure).

[w0rp]

I can try installing Vim and ALE on Windows again. I still might not be able to repeat the bug myself. I recommend having a go at fixing it.

[NewUserHa]

hope so. and I double checked this issue only appears while ALE is enabled.

ps. according to the above comments, ArchLinux(gvim), mac(vim?), windows(gvim) will have this issue.

[w0rp]

This never went anywhere.

[busticated]

well, fwiw, i'm still hitting it every now and again. still no idea how to provide a solid repro beyond what's captured above though so 🤷‍♂

[w0rp]

I could never repeat the bug. If you can ever figure out what causes it, please submit a patch for it.

[NewUserHa]

using gvim 64 8.1.1967. this bug still be there.

how couldn't repeat it?

[NewUserHa]

I found let paste#paste_cmd = {'n': ":call paste#Paste()<CR>"} in paste.vim. can it help?

edit: after I recalled some function defined in paste.vim and mswin.vim. it start to get :call paste#Paste()<CR> by press c-a,

[w0rp]

I've never experienced the same bug. If you'd like to try to fix this, feel free to git clone the repo and give it a go.

[NewUserHa]

I really want to but I don't figure out what's the reason since I'm some new to vim.

But I tried to find out then post the infos above for help fix. other guys encounter this issue as well. I don't know what can explain this issue better more than the gif in older comments.

I guess it's caused by mswin.vim and something. I'd like to assist if you like

[busticated]

@w0rp i know it's asking a lot so no worries if you'd rather not but fwiw, i'd be happy to jump on a hangout and repro the issue in real-time. it's happens to me ~85% of the time. if in repro'ing it you can better diagnose possible root causes / point me in a general direction, i can take a crack at a fix and / or report the details back here for others to take a swing at. again, no obligation but i figured i'd offer since it's such a weird issue.

thanks again for an awesome plugin :pray::+1:

[w0rp]

I'll reopen the issue, and someone else can have a go fixing it. I think whoever can reliably reproduce it might have a better chance of fixing it.

[NewUserHa]

I guess it may be some codes (maybe ale) cause lag to vim to bug mswin.vim or something else to cause this finnal result. I enabled all plugins so not sure has relation with this, but I can feel lag when enter a new line with auto indent, and I saw the same issue with :update or gg(and something) instead :call paste#Paste()

[georgeharker]

for me this seems 100% repeatable if i enter insert mode via i, then double click to select a word (so the mode is now (insert) visual). Cmd-v in that mode will reliably paste the contents, but it won't in the non insert visual mode. Can't quite figure out what's going on, but does that help your understanding?

[georgeharker]

I take that back, it was, now it isn't - I think the error / location window has to be open

[georgeharker]

confirmed, I can repro 100% if

1. The error / location window is open (make a syntax error, see that it highlights with >>)
2. i use i key to enter insert mode then double click to highlight a word ie (insert) Visual mode, importantly, on a line with an error >> marker (it doesn't actually need to show the sign marker, just be in error state)
3. hit paste via command-v (i'm on a mac, you might need C-v)

I'm not sure if g:ale_open_list has to be 1, mine is, but it looks like setting it 0 has the issue also - you just need to have a syntax error in the file on the line so that the error highlight is shown.

So syntax is on, my vim has signs, but setting g:ale_set_signs=0 still does the same.

Tried various options / globals, it looks like the specific functionality at issue is is g:ale_echo_cursor, with that set 0, the above does not happen any more, but set to 1 it does.

Hopefully narrowing down to the option that causes it might help. Hopefully it helps repro also.