Mark/Copy has a delay prior to copy

[taer]

Using the latest 170227 relase.

This existed in the prior 16XXXX release I had. I have the "Copy on Left Button release" set in Mark/Copy, and in mouse, "Mouse button actions", Middle is set to paste. I'm trying to emulate xterms in Xwindows.

This works, but you have to wait about a half second between the highlight and the middle click. Is this intentional? I enabled the "Reset selection on Left Button release" to visually see when the copy has taken place. It has this fairly long 1/2 second delay prior to it actually copying the highlighted text. This is different than a normal xterm(where it really is immediate).

Can an option be added to eliminate this delay?

Thanks

[Maximus5]

So, you press LBtn, drag mouse to select text, release LBtn, and at that moment observe delay before copying to clipboard? Perhaps the delay has effect on the screen repaint only?

[taer]

I just enabled that to double check. What I originally noticed was I had something in clipboard. I'd highlight a word, and middle click. It would paste the original clipboard contents in. If I highlight and wait about a half a second before middle clicking, it would work correctly.

I also tried highlight followed by control-v to paste. The same thing occurs.

It doesn't matter if I click drag highlight, or double click to highlight a word. They both require the same patience. :)

[taer]

Using 161206, I tried the same operation. The delay is still there for middle click, but right click pastes instantly.

So in summary, doubleclick to highlight, then immediate middle click. I get the old clipboard. doubleclick to highlight, then immediate right click. I get the highlighted text paste as expected.

[Maximus5]

Show your settings. I think it's due to your configuration... Paste does not imply preceding Copy. http://conemu.github.io/en/SettingsMarkCopy.html#id2340

[stenyak]

I suffer the same problem.

After tinkering with all possible settings, I've found out that activating "Reset selection on Left Button release" is what introduces the halfsecond lag of the Copy.

Deselecting that option will fix the order of operations, so you can Copy then Paste, and it will work regardless of your clicking speed.

[pkasting]

I can reproduce this issue with 161206.

If I double-click a word and immediately press middle mouse, I get my previous clipboard contents on that and all future pastes. If I double-click, wait about a half second, and then press middle mouse, I get the updated clipboard contents on that and all future pastes.

Attaching an image of my settings. I do not have "reset selection on left button release" set.

[Maximus5]

It is expected behavior.

As I understand you have chosen Paste action for Middle mouse button (IMHO Right button is more handy). So, Middle button does not do copying and pastes current contents of the clipboard.

The copying is done by timer because of click/double-click/triple-click. And Copying is not implied by Paste action.

If you want proper paste of selected text or clipboard contents you have to use Auto actio for your middle mouse button.

[pkasting]

So "auto" means "immediately copy the selection to the clipboard, then paste it"? I could live with that.

Out of curiosity, why not copy as soon as you have a changed, non-empty selection due to a mouse event, instead of waiting for a timer (presumably, a timer set to the system double-click time)? In that case, if the user is triple-clicking (for example), you'd copy immediate on double-click and then copy again on triple-click, which seems OK.

[Maximus5]

Copying takes time. Copying puts to clipboard unwanted data, some applications monitor the clipboard and ConEmu may just fail to copy text twice. Moreover, copying is not required if you want just to paste the selected text immediately.

[Maximus5]

Also, implementation of "reset on copy" conflicts with double and triple-clicks.

[pkasting]

"auto" seems to cause unpredictable behavior:

• Sometimes, middle-clicking clears the current selection without pasting anything, then clicking again pastes.
• Sometimes, middle-clicking (quickly after double-clicking) pastes the current selection once, but repeated clicks paste the old clipboard contents (so, basically, the middle click did not force a clipboard update, and the selection was cleared before the timer kicked off).

I agree that "reset on copy" is incompatible with automatically copying. I don't have a solution to that, other than to not do the behavior I'm proposing in that case. OTOH, the other objections you raise seem to be addressable. (I'm one of the folks who's worked on clipboard implementation stuff in Google Chrome, so I'm not entirely unfamiliar with this space.) Copying does take time, but not enough time to actually notice when triggered by user actions (since those are comparatively slow and infrequent). Copying does alert other applications monitoring the clipboard, but that's sort of desirable in this case. I'm not sure what would cause a failure to copy twice; maybe if a monitoring app reads the clipboard change and modifies the clipboard on a timer itself? But in that case it would interfere with copying once too. As for copying not being required if you paste immediately, the problem there is that the pasted text wouldn't reflect the clipboard state, so (as noted above) repeated pastes don't get the same value.

Basically, I'm attempting to reproduce a typical Linux bash environment, where middle-mouse would cause the current selection to be copied to the clipboard immediately and then pasted. It seems like "auto" doesn't quite do that, and "paste" doesn't work because copying isn't auto-triggered on mouse-based selection changes. I don't know how else to achieve this.

[Maximus5]

auto works on strict rules:

• if you click inside selection, the selection is pasted internally, without modifying Windows clipboard. That's very useful, because you have your clipboard intact (c++ code snippets or so) and the paste was done.
• if you click outside of selection, the copy operation is done.

[pkasting]

I see. I don't want either of those behaviors, so it sounds like auto is not for me.

I don't know if you have any proposal for how to better emulate the Linux sort of behavior via the "paste" mechanism.

[0anton]

I am also suffering from a delayed copying. Got rubbish in the console, because of it. Trying removing checkbox on "Reset selection on Left Button release", as @stenyak suggested. Will keep informed.

Current behavior is definitely an expected one - I'd expect immediate paste when some text is selected and paste button is pressed. I think @pkasting made a good point at Sep 11, 2017 - as soon as buffer is selected and user press 'paste', the click-timer has to be cancelled and paste immediately be performed. There is no sense to wait for the double-click or tripple-click. The user already has indicated through action, that he wants the paste, the second click won't follow - the sequence is already broken. Max, please, review!

[Maximus5]

What about 190301?

[pkasting]

I installed it, but it doesn't seem to fix my testcase:

• Select some text with left-drag
• Immediately press middle-click to paste

Expected: Selected text is pasted Actual: Previous clipboard contents are pasted

[0anton]

I tried the last build and can confirm immediate paste of selected area without any delay. Thank you Max for improving Conemu in that aspect!

On Sat, Mar 2, 2019 at 3:49 AM pkasting [email protected] wrote:

I installed it, but it doesn't seem to fix my testcase:

• Select some text with left-drag
• Immediately press middle-click to paste

Expected: Selected text is pasted Actual: Previous clipboard contents are pasted

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Maximus5/ConEmu/issues/1053#issuecomment-468875242, or mute the thread https://github.com/notifications/unsubscribe-auth/AQgg5C9-U-_20By5ljweAg8Ne7sleH63ks5vSea1gaJpZM4MO-FI .

[Maximus5]

@pkasting Try with ConEmu64.exe -basic -run {cmd}.

[pkasting]

Using that, the mouse buttons don't have the same functions as in my case, but I still see a delay-based difference:

• Select some text with left-drag
• Left-click once to cancel dragging
• Right-click to paste text

When doing all three steps in very rapid succession, the pasted text is the previous clipboard contents. If I wait a bit after the initial left-drag, the pasted text is the dragged text.

[infernix]

I'm on 190310. I have:

• copy on left button release checked
• Reset selection on left button release unchecked:

With middle button set to paste:

• double-clicking a word, not moving the cursor off of it, and immediately clicking middle button: pastes the existing clipboard selection (and not the selected word)
• double-clicking a word, not moving the cursor off of it, and waiting a second: pastes the selected word
• double-clicking a word, moving the cursor off of it, and waiting a second: pastes the selected word

With middle button set to auto:

• double-clicking a word, not moving the cursor off of it, and immediately clicking middle button: pastes the selected word
• double-clicking a word, not moving the cursor off of it, and waiting a second before clicking middle mouse button: pastes the selected word
• double-clicking a word, moving the cursor off of it, and immediately clicking middle button: copies the selected word. pasting needs another click.
• double-clicking a word, moving the cursor off of it, and waiting a second before clicking middle mouse button: copies the selected word. pasting needs another click.

It seems there's currently no way to get consistent behavior?

What I would like to see is that it always does a copy & paste of the current selection using middle click (perhaps add copy+paste option) regardless of mouse cursor being on the selection or not. Copying the contents to the clipboard (for use in other applications) can be done asynchronously

[infernix]

Copying takes time. Copying puts to clipboard unwanted data, some applications monitor the clipboard and ConEmu may just fail to copy text twice. Moreover, copying is not required if you want just to paste the selected text immediately.

@Maximus5 is there a technical limitation here? It's extremely frustrating to select text in 1 conemu-cyg-64 instance and then paste it into another conemu-cyg-64 instance, only to find out that I went too fast and it's pasting the old clipboard buffer instead of what I selected. It's happening dozens of times throughout the day.

[infernix]

So an update. I looked at the source, and if I change the windows double click time in mouse settings to the shortest time possible, this issue is fixed for me.

I see a few references to GetDoubleClickTime() in RealBuffer.cpp function CRealBuffer::OnMouseSelection: https://github.com/Maximus5/ConEmu/blob/12ba6e932473686d571895864a5804b5427e18b1/src/ConEmu/RealBuffer.cpp#L3997

I haven't looked at which one it is, but I'm sure one of these is causing the delay in filling the clipboard buffer.

I have a workaround now at least by setting the Windows doubleclick speed to the fastest setting, but I suspect there's some delay here in pushing data to clipboard where it's waiting for a doubleclick event (which never happens if we push down left button > drag to select > release left button).

This fixes it both in the situation with middle button set to auto as well as paste.

[pkasting]

Maybe the very last one on line 4033 -- if LBUTTONUP happens less than double-click-time after the last event we don't copy immediately. Seems like there are multiple non-mutually-exclusive fixes:

• If the auto copy timer is set and the user requests to paste, force the copy to happen immediately first, on the assumption that's what they wanted.
• Since double-clicks only apply when a drag hasn't happened, once the user has dragged beyond the system drag initiation threshold, we should never be looking at double-click times. In particular, after a mouse drag that selects text, always copy immediately, because checking the double-click time doesn't make sense.

[rp-pedraza]

Maybe it's a good idea to just add another explicit feature like "Always copy text to clipboard on select".

[rp-pedraza]

@infernix

So an update. I looked at the source, and if I change the windows double click time in mouse settings to the shortest time possible, this issue is fixed for me.

Thanks, this works for me as well (most of the time).

Update: And it's at the expense of having to double-click faster in the explorer when opening folders/files.

[kgfly]

If you right click in Windows 10 default console to copy, there is no observable delay at all. So I think conemu should match this behavior.

[vvuk]

Since double-clicks only apply when a drag hasn't happened, once the user has dragged beyond the system drag initiation threshold, we should never be looking at double-click times. In particular, after a mouse drag that selects text, always copy immediately, because checking the double-click time doesn't make sense.

This seems very reasonable. Any reason a PR to do this wouldn't be accepted?

[pkasting]

FWIW, this behavior is still unchanged (and still trips me up ~daily) four years later. @Maximus5 Any interest in a PR to implement part or all of https://github.com/Maximus5/ConEmu/issues/1053#issuecomment-484909936 ? If you'd take that behavior change, I could probably implement at some point.