Right-click paste drops characters

[conan]

Versions

ConEmu build: 161206 Stable x64
OS version: Windows 10 Build 17025.rs_prerelease.171020-1626 x64
Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): Bash for Windows

Problem description

Copy/pasting with mouse left click/right click doesn't seem to work consistently; only the end of the selected text is pasted, rather than the whole selection. Selecting and pasting the same text multiple times results in a different number of characters from the end of the selection pasted each time (between around 4 to 15).

I noticed at the same time this began happening, a user macro I have that runs print("\e echo -e '\0033\0143' \n") started only writing echo -e '\0033 to the console (it's meant to clear the screen, hence the newline at the end). This behaviour is consistent though, so may be unrelated.

Steps to reproduce

1. Select text with mouse left click + drag
2. Click to put cursor in terminal
3. Right click to paste

Actual results

Last few characters are pasted (number of pasted characters varies each time, but is consistent for each selection)

Expected results

Selected text is pasted

Additional files

[conan]

I've tried with all the combinations of settings that seemed relevant in Mark/Copy and Paste.

This occurs on two separate laptops running Windows 10 Pro.

[ronindesign]

Not sure if my issue is exactly the same, but it seems quite close, maybe similar causes.

ConEmu Build: 161206 stable x64
OS version: Windows 10 Build 17025.rs_prerelease.171020-1626 x64
Used shell version (bash, wsl): Bash for Windows

Description of Problem

When copying from external source (browser, another console, text editor, etc), and then attempting to paste into ConEmu running Bash on Windows (WSL), results in malformed pastes.

Some observations (all tested with right-click, ctrl+v, insert):

• Malformed pasting behaves same way each time (in bash)/zsh):
  • Paste text once and see it is malformed.
  • <Ctrl+C> to clear / reset command line.
  • Paste text once again, it has exact same malformation as first step.
• Pasting multiple times seems to have additional (probably not) random effect:
  • Copy example text: Lorem Ipsum is simply dummy text of the printing and typesetting industry.
  • Paste once: nothing is printed
  • Paste again: sometimes nothing, sometimes few random characters from copy
  • Paste 5 times quick as possible: random result, examples: itry., Lorem tting, sstry.
  • Hold down paste: random sets of characters, example y.tsntingLoesettingstingimps tingLorsetting textingrintingimpltypesetting ingLoreettingitry.

Maybe there is an issue transferring clipboard contents between windows / other applications and ConEmu?
Also, I noticed the WSL release notes mentioned changes to paste functionality
https://msdn.microsoft.com/en-us/commandline/wsl/release-notes

• Biuld 16257 - Fix copy/paste behavior for console/tty, and add better full buffer handling [GH 2204, 2131]
• Build 16241 - Cannot paste particular characters [GH 2149]

[gijsk]

Same thing happening to me with ConEmu 171109 preview on Windows 10 Build 17035.1000 (windows insider fast ring).

[Maximus5]

1. I do not observe malformed pasted text. Perhaps your description is not complete.
2. Reports for stable build 161206 has almost no value. It was released a year ago and new stable will be released soon.
3. If you do not use connector+bridge (standard {bash} task generated for you by ConEmu, most issues are not related to ConEmu at all.

Further troubleshooting is required from you

• Due to settings from the issue, the selected text is immediately placed into Windows clipboard. So, you may ensure that it's OK by starting Notepad (for example) and paste the text there after step 1.
• You click in the terminal in step 2. What for? You may press right mouse button immediately. Moreover, left-click has no sense - it just resets the selection, "cursor" is not changed with left-click at that moment. The same you may do with Esc key. Anyway, you shall to validate clipboard contents after step 2. Go to notepad and do the paste.
• At last. If the clipboard contents is OK, run the command ConEmu64.exe -basic -run cmd /d from Win+R, and try to paste some certain text (copy it from Notepad or so). In my tests I have no glitches in 100% of tries. But I'm using Win 10 version 1709 (build 16299.19).

[ronindesign]

For my situation:

1. I will tried to provide additional info / troubleshooting
2. I've tested all the way up to alpha, the malformed paste still occurs.
3. I can reproduce this with the standard {bash} task generated by ConEmu.

I will review your further troubleshooting and follow up.

[conan]

I'm using the {Bash::bash} task I found in ConEmu, I did not create my own task to run a WSL terminal in ConEmu.

Troubleshooting:

• Yes, full text makes it into the windows clipboard.
• This is an old habit from Windows terminals, and you're right, it's not relevant to this behaviour. Sorry.
• Yes, contents are pasted fine into ConEmu64.exe -basic -run cmd /d with no loss of characters

I've noticed the problem only seems to occur when the text being pasted contains spaces; the more spaces in the text, the fewer characters get pasted. If I have more than about 3 spaces then usually nothing gets pasted.

Here's an example of writing some text, then copying it and pasting once per line (pressing ctrl+c at the end of each line):

[Maximus5]

Just created test build of connector.
https://www.dropbox.com/s/m1fpkw3kei2wgre/conemu-cyg-64.exe.1.2.3.7z?dl=0

With --log switch it dumps all received input to connector-XXXX-in.log in the same directory where connector is located (%ConEmuBaseDirShort%). So the test variant of {Bash::bash} is:

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --log --wsl -cur_console:pnm:/mnt -t bash -l

It's intersting what would you see in the log after consequtive Ctrl-V, Ctrl-C, Ctrl-V, Ctrl-C, ...

Perpahs this issue is related to gh-1311.

[conan]

Update servers are working again so I've pulled the latest preview build (171109). (I wasn't able to run the file with my existing stable build, it complained about not having cygwin1.dll).

I don't seem to have %ConEmuBaseDirShort% on my system, but putting that file in the Program Files\ConEmu\ConEmu instead and updating the task appropriately gets it running. Pasting seems to work fine (including spaces) but occasionally the console locks up completely (doesn't accept any input from typing or pasting). I don't know how to find that log file, but I do now have the wsl folder in there with some wsl* things I didn't have before.

Incidentally, my clear screen macro works in there as well, so it seems likely the two problems are related.

[Maximus5]

So, your problem was in the stable build. I suggested to update it previously.
This issue is closed. Locked console is discussed in gh-1311.

[conan]

Yes, I was reporting a bug in the latest stable build (161206). The problem still occurs in the latest preview build (171109) as well. Does the fact that you've closed it mean it's fixed in an alpha build?

[Maximus5]

What shall I write to avoid old-builds-issues? The message is not clear?

[ronindesign]

You should define what an old build is, instead of using a relative / ambiguous term.

I, and I'm sure many others, read that as old meaning "older than current stable".
Using an older than stable build can often cause problems, so this is an understood concept.

Maybe another system for versioning is in order if stable is too old to report bugs on... (yet this seems like a contradiction), this would not be obvious to me.

In any case, this issue relates to all the builds up through current alpha...

[conan]

Sorry, I rely on ConEmu so much for daily productivity that I'm generally not prepared to be running anything but stable builds. This may be my own misunderstanding of what is meant by "stable", but I generally take the same approach with all of my critical tools; I'm already very uncomfortable running an insider version of Windows.

Also yes, I interpreted "old builds" to mean anything older than the latest stable build.

I've tested this problem with both the latest stable and preview builds, and the problem occurs in both cases. Only when running bash using the file you sent (above) was the problem resolved, but I experienced a far worse problem (freeze) which prevents me from using it. Is this problem fixed in an alpha build?

[Maximus5]

@ronindesign

You should define what an old build is, instead of using a relative / ambiguous term.

But there is the definition in the screenshot (issue template).

ConEmu versions has following format `YYMMDD`, so if you are using old build,
there are chances that your problem was fixed long ago.

In any case, this issue relates to all the builds up through current alpha...

But that is not confirmed. Or do you mean freezes?

@conan

Sorry, I rely on ConEmu so much for daily productivity that I'm generally not prepared to be running anything but stable builds.

That's clear and that's why I recommend to use Preview builds. Personally I'm using Alpha ;)

Only when running bash using the file you sent (above) was the problem resolved,

I believe that if you take connector from the Preview and use Default task {Bash::bash} you'll see the same behavior.

but I experienced a far worse problem (freeze) which prevents me from using it. Is this problem fixed in an alpha build?

At the moment there are no build newer than Preview.

[gijsk]

In any case, this issue relates to all the builds up through current alpha...

But that is not confirmed. Or do you mean freezes?

I see the same issues with copy/paste in the preview build, as noted in my earlier comment. If it matters, I'm using an msys bash shell that's part of mozilla-build ( https://wiki.mozilla.org/MozillaBuild ).

[Maximus5]

@gijsk

I see the same issues with copy/paste in the preview build

If you don't use connector, it's not a ConEmu issue.

[gijsk]

@Maximus5

If you don't use connector, it's not a ConEmu issue.

Sorry, I'm confused. I don't use the connector executable. I'm sure this is a dumb question, but the pasting issue doesn't occur when running the exact same shell "normally". That is, it's a bat file, I double-click the bat file in windows explorer, copy/paste works correctly in the resulting shell. I start the bat file as the only command that makes up a shell setup in ConEmu, and copy/paste doesn't work correctly with the result being mangled as described in this issue. Why wouldn't that be a ConEmu issue?

[Maximus5]

It depends on many factors.

When you run some application without ConEmu, you see the conhost window and all input (Windows WM_CHAR and others) is translated into console events internally by Windows kernel (conhost) without using WinAPI.

Second. When you run application in ConEmu, I have absolutely no other way to post key sequences into console input buffer than Windows console API (conhost doesn't use it). Moreover, there are many ways to read that input and it depends on the console application which API function is use.

Third. In the issue there are confirmations that in some configurations there is no input loss (freezes is offtopic here). So it can't be obvious ConEmu bug, because I always use one way (defined console API) to post keypresses in the console input queue. If the console application can't read correct input, that means the queue is broken inside conhost.

Fourth, when you don't use connector (why? all cygwin/msys/wsl default tasks created by ConEmu use it), I have less control over console processes. Actually, when you run WSL without connector - absolutely no control.

At last. I'm not sure, comments are messed up, but seems like messed input was detected in the last insider builds of Windows 10. And the issues doesn't depends on ConEmu build (stable was released about a year ago).

All these reasons make me almost sure, that this is a Microsoft bug, like this known and reported.
@miniksa Can you verify that?

[conan]

In response to your question about the connector, I've tried setting it up several times but have never understood the documentation enough to know what to do with it. I found it difficult to understand what I need to download and where to put those things. I also don't understand what it does. For these reasons the minor benefit it got me (allowing me to list the directory in the tab name) didn't seem worth the couple of hours I've already sunk into trying to make it work (and often breaking my ConEmu in the process).

[Maximus5]

No need to download anything. Connector is included in the latest builds and default tasks are created for you.
ConEmu64.exe -basic for check.

[miniksa]

I tried the code in https://github.com/Maximus5/ms-bug-2 on Windows 10 17039 (in my team's branch, not RS_PRERELASE) this morning with the v2 console and it doesn't repro. Is that what you wanted me to check?

[Maximus5]

Nope. As I understand, current issue is occurred with ConEmu and bash for Windows.
Unfortunately, neither user have provided exact command line they use.
Hm, now I understand that repro steps are absent in the issue.

To check further we need the command, the versions and the steps.
For example

• Run ConEmu.exe -basic -run wsl.exe
• Paste the string bla bla bla using Ctrl-V dozen of times...

[ronindesign]

Apologize for absent details on my part.

I will test this shortly and update my comment.

[jcrawfordor]

For what it's worth, I was experiencing a very similar issue when running zsh in WSL in conemu. Actually before discovering this bug I did a repair install and the problem seems to have just gone away - I'll keep a close eye on it.

[ronindesign]

Edit: for formatting / styling clean-up

Note: for all testing below I used ONLY some combination of the following 4 inputs:
<Left-Click> <Right-Click> <Ctrl-C> <Ctrl-V>

Alright, I've tested some more, first starting with the (most recently) requested.

Run ConEmu.exe -basic -run wsl.exe

Test string used for pasting (I made absolutely sure it was plain text, no special encoding, chars, etc):
Lorem Ipsum is simply dummy text of the printing and typesetting industry.

Exact steps done:

• <Win-R> to open Run dialog, enter cmd, click OK.
• In open command prompt, ConEmu is not in my path so I chdir to C:\Prog...\ConEmu
• I have no ConEmu.exe (assuming due to 64-bit install) so I use following command instead:
  ConEmu64.exe -basic -run wsl.exe
  The following are the test results from different trials using combination ONLY of keys above and trying to wait several seconds between each action:
• Left click to focus newly opened ConEmu window.
• <Ctrl-V> without ever entering <Ctrl-C>, 0 - 5 times nothing appears, 7th time I get:

$ ting

• Again, <Ctrl-V> (still without a single <Ctrl-C>) 3 more times nothing appears, 4th time I get an additional g, now the terminal line looks like:

$ tingg

• Again, <Ctrl-V> (still without a single <Ctrl-C>) 1 more time nothing appears, 2nd time I get an additional im, now the terminal line looks like:

$ tinggim

• Again, <Ctrl-V> (still without a single <Ctrl-C>) 1st time I get an additional dustry. (note this is the end of the paste sequence, if that's significant), now the terminal line looks like:

$ tinggimdustry.

• Again, <Ctrl-V> (still without a single <Ctrl-C>) 1 more time nothing appears, 2nd time I get an additional inting, now the terminal line looks like:

$ tinggimdustry.inting

• Now I press <Ctrl-C> once. Repeat similar trials again, only using <Ctrl-V> for paste, and not using <Ctrl-C>. However, Now enter <Ctrl-V> as quickly as possible, for different number of times:

• 5x <Ctrl-V>, nothing has pasted so far, resulting in current state looking like:

$ tinggimdustry.inting
$ 

• Again, 5x <Ctrl-V> more, on 2nd paste the segment stry. is produced (again, end of paste string), terminal now looks like:

$ tinggimdustry.inting
$ stry.

• Again, 5x <Ctrl-V> more, on 3nd paste the segment ypesetting is produced (again, end of paste string), terminal now looks like:

$ tinggimdustry.inting
$ stry.ypesetting

• Now 10x <Ctrl-V> more, hard to tell when, but 3 times partial text appeared, resulting in total sum of Lorsettingstry. pasted characters. Terminal now looks like:

$ tinggimdustry.inting
$ stry.ypesettingLorsettingstry.

• <Ctrl-C> again so we have fresh line, still trialing 10x pastes:
• 10x <Ctrl-V>, 1 paste occurred, new text imp., terminal now looks like:

$ tinggimdustry.inting
$ stry.ypesettingLorsettingstry.
$ imp.

• Again, 10x <Ctrl-V>, 1 paste occurred, new text ndustry.ingLoreetting, terminal now looks like:

$ tinggimdustry.inting
$ stry.ypesettingLorsettingstry.
$ imp.ndustry.ingLoreetting

• Then, I enter one <Ctrl-C> for fresh line.

• Now I run time based trials, holding <Ctrl-V> for number of seconds, and show results.

• 5 sec <Ctrl-V>, produces:

$ tinggimdustry.inting
$ stry.ypesettingLorsettingstry.
$ imp.ndustry.ingLoreetting
$ tingsetting textingrintingimpltypesetting ingettingiextIpsngintingimplyypesettingngttingimxtgntingLopesettinggtingimp

• One single <Ctrl-C> for new line.
• Again, same trial, 5 sec <Ctrl-V>, produces:

$ tinggimdustry.inting
$ stry.ypesettingLorsettingstry.
$ imp.ndustry.ingLoreetting
$ tingsetting textingrintingimpltypesetting ingettingiextIpsngintingimplyypesettingngttingimxtgntingLopesettinggtingimp
$  tingLorsetting textingrintingimpltypesetting ingLoreettingiextngintingimplyypesettingngLoremsttingimxtgntingpesettinggting

(Note: last line starts with a space)

• One single <Ctrl-C> for new line.
• Now, 10 sec <Ctrl-V>, produces:

$ tinggimdustry.inting
$ stry.ypesettingLorsettingstry.
$ imp.ndustry.ingLoreetting
$ tingsetting textingrintingimpltypesetting ingettingiextIpsngintingimplyypesettingngttingimxtgntingLopesettinggtingimp
$  tingLorsetting textingrintingimpltypesetting ingLoreettingiextngintingimplyypesettingngLoremsttingimxtgntingpesettinggting
$ intingimplyLypesettingngoremttingimxtgntingLopesettinggtingimpttingesettingsingprintingimplingLoresettingextngrintingimplyypesettingngLoremettingixtgintingimply LpesettinggLorem ttingimtntingesettingtingimp tingLorsetting textingrintingimpltypesetting ndustry.

It appears to me the relationship between rate of pasted text is linear with time when holding the <Ctrl-V> continuously trying to paste.

Next I test:

You may try this patch for connector until new ConEmu build arrives
https://www.dropbox.com/s/ifwi0asv5ou09ab/connector.171109a.7z?dl=0

[ronindesign]

So the following fixed pasting for me:

• Installing fresh: ConEmu (b171109x64)
• Setting task as described above:
  1 {Bash:bash}
  Commands:

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --log --wsl -cur_console:pnm:/mnt -t bash -l

This resulted WSL starting correctly ,and <Ctrl-V> pasting without any further issue.

This was tested in few different environments:

• Users: root, main user
• Shell: bash, zsh (launched inside terminal, e.g.via .bashrc)

Edit: I also tried to get --log switch to work and output log, but even when running As Administrator, no log seems to appear anywhere in C:\Prog...\ConEmu directory tree.

[Maximus5]

Build 171117 has been released.
It would not fix paste dropped characters problem in bare wsl, but it contains latest connector and I hope connector Tasks are working properly now.

[conan]

I've installed that version. My {Bash::bash} task still looks like this:

%windir%\system32\bash.exe -cur_console:pm:/mnt --login -i -new_console

It still has the problem. I'm afraid I don't really understand what you mean when you say "why don't you use the connector" - I installed ConEmu and used the built-in {Bash::bash} task. Does that not use the connector? If not, that's why. If it does, then I am using it.

Using the command line pasted above in a new, custom task fixes the problem:

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --log --wsl -cur_console:pnm:/mnt -t bash -l

I previously ran the file you pasted above in dropbox; this created the ConEmu\ConEmu\wsl folder, but I don't know whether the build 171117 update I just installed changed that or not.

[ronindesign]

I believe using the bash.exe directly does not use the connector.

For example, you say you have for your task {Bash::bash}:
%windir%\system32\bash.exe -cur_console:pm:/mnt --login -i -new_console

I, personally, replaced everything in my {Bash::bash} task with the following:
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --log --wsl -cur_console:pnm:/mnt -t bash -l

I believe this does use the connector and is how I'm now using the bash terminal on windows.
Specifically, I'm no longer connecting directly to the bash.exe.

If there is no reason to not use the connector, I would say just replace your bash task with the custom task commands and run that way instead of the default \bash.exe way.

[Maximus5]

ConEmu recreates default tasks on demand only
http://conemu.github.io/en/Tasks.html#add-default-tasks

[ltomes]

@ronindesign's suggestion is working well for me on build 171117.

[rymanske]

Using @ronindesign and @conan's suggestions on build 171117, I've found that pasting now works but keyboard input lags noticeably. Has anyone else experienced that?

[ltomes]

@rymanske My understanding was this is a windows issue in general

I experience lag but in my case it's the same as what I experience with 'Bash on Ubuntu on Windows' directly I believe.

Latency was reduced by removing extra features from my PS1 (git completion was noticeably slow as described here).
Let us know if you can nail down something in conemu that is adding latency/can be improved! I am all for a faster environment.

[ronindesign]

@rymanske check if you experience same lag in regular, non-ConEmu bash.exe as @ltomes mentions.

I went through the pain of diagnosing the "prompt lag", that I believe @ltomes is describing.
However, it sounds like this might not be the same issue your having... could you elaborate on what "keyboard input lag" looks like for you?

The issue with the prompt is very noticeable each time the prompt loads for a new line, might take .5 - 2 seconds to load the prompt (even when simply via <Ctrl-C>).
If instead your actual keystoke inputs are delayed, i.e. you type key, wait, and then finally letter appears, this I am unfamiliar with and have not experienced.

[rymanske]

@ronindesign @ltomes The lag is not very noticeable when typing a single letter. It just gets choppy when I type at a reasonable speed. I've attached a video demonstrating the lag. It's a bit subtle so I also including a video without lag for comparison: LagClips.zip

I only started experiencing the lag in ConEmu after replacing everything in my {Bash::bash} task with
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --log --wsl -cur_console:pnm:/mnt -t bash -l

I see no lag when using the typical bash.exe in ConEmu or the Windows Command Prompt.

[Maximus5]

https://conemu.github.io/blog/2017/12/03/Build-171203.html

Ref gh-1332

[ltomes]

@Maximus5 I just installed build 17.12.03 and see the same behavior for gh-1314 (Can't copy paste if I revert to task
%windir%\system32\bash.exe ~ from set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --log --wsl -cur_console:p:pnm:/mnt -t bash -l )

If that is not supposed to be fixed in 17.12.03 and you are posting in regards to @rymanske's issue / gh-1332 please disregard my comment.

[rymanske]

@ltomes My issue is resolved in build 171203.

[Maximus5]

@ltomes If you run %windir%\system32\bash.exe ~ without connector you should address bugreport to Microsoft.

[RichardBronosky]

There's a lot of talk here about "connector" and I have no idea what that is. Someone please give a clear explanation on how to fix this for someone who has used Unix and Linux exclusively and is just touching Windows for the first time now that it has WSL.

[Maximus5]

I believe clear explanation exists in docs. Have you read them?

• BashOnWindows in ConEmu
• cygwin/msys connector

[Maximus5]

TLDR;

• Install ConEmu
• If it was installed before, recreate Default Tasks
• Run {bash} Task

[dylanh724]

This issue still happens in the latest, stable version -- not sure why this issue is closed (found @ the top of Google).

If I were to paste this:

url -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

The result pasted is:

//download.docker.com/linux/ubun

[Maximus5]

The issue is closed because when you use properly generated tasks it's fixed.
What shell do you use and how do you started it?