Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lag when clicking in msys2 bash shell with gvim running in background #845

baldurk opened this issue Aug 30, 2016 · 2 comments


Copy link

baldurk commented Aug 30, 2016


ConEmu build: 160828 stable x64
OS version: Windows 7 SP1 x64
Used shell version: msys2

Problem description

When I launch windows gvim as a background command from bash, I experience a small lag when clicking on the shell. From running a debug build it seems to be caused by a named pipe timeout looking for a pipe that wasn't created.

Steps to reproduce

  1. Open a ConEmu shell using msys2's bash. login command is "C:\msys64\usr\bin\bash.exe" --login
  2. Begin an instance of gvim.exe in the background. I think this might happen with other programs, but this is my repro: /c/Program\ Files\ \(x86\)/Vim/vim74/gvim.exe &
  3. Click on the console, each click will cause a lag of about 1 second before input then catches up.
  4. Close vim, it goes back to normal, you can repeat 2-4 as many times as needed.
  5. In a debug build, after the lag the error message will pop up "Pipe open failed with timeout!" with "CreateFile(.\pipe\ConEmuHk19532) failed code=2, Tries". See additional files below, 19532 corresponds to the PID of an intermediate bash.exe, below the login shell that is the parent of gvim.exe.
  6. If you open the real console with Ctrl+Win+Alt+Space, it doesn't experience any lag when clicking into it and typing - but when clicking on ConEmu then the lag applies to both ConEmu and the real console.

Actual results

Every click causes an approximate 1s lag before normal running resumes.

Expected results

No noticeable lag.

Additional files

I'm not sure how to get a log of what I saw in the debug build, I looked in info -> debug but none of those logs showed anything to do with the pipe failure.

I've found a workaround just by greatly reducing the pipe timeout, but this obviously isn't a real fix.

Process explorer screenshot showing the process tree with the handles open (see that there's no named pipe on PID 9396):


And showing the DLLs, that there is ConEmuHk64.dll injected:


These screenshots are from my debug build (so I can show the named pipe error - that's also why it says "Duration" instead of "Tries" now because I reduced the timeout to 10ms). The same applies to the installed build I have, the DLL is present in the child bash.exe but there is no pipe.

In case it's relevant, here is my settings.xml. I have "Inject ConEmuHk" enabled, but this option seems to make no difference (the problem is the same, and the DLL seems to be injected even if it's disabled).

Copy link

Maximus5 commented Aug 30, 2016

The answer depend on your case. Why do you click? What is expected reaction for the click?

Copy link

baldurk commented Aug 30, 2016

I use sloppy mouse focus (focus follows cursor), so I often click on the window just to raise it to the foreground. For this reason also I have "Skip click on activation" and "Skip mouse events in background" disabled.

I tried disabling "Change prompt text cursor position" but it didn't make any difference, I still get the lag when clicking to raise, or if I double click to select a word. Ideally I would like to leave this enabled since I might run terminal programs sometimes that I will want mouse input for.

As far as I can tell, everything works correctly with my settings except for this lag. I haven't noticed anything else working unexpectedly at least.

Maximus5 added a commit that referenced this issue Jan 18, 2017
  Ref: gh-986, gh-317, gh-845

  Now ‘Change prompt text cursor position with Left Click’
  and ‘Ctrl+Backspace - delete word leftward to the text cursor’
  are process by ConEmu GUI without posting command to ConEmuHk.

  The feature requires properly reported by the shell prompt start pos.
  For bare cmd.exe it's done automatically by ConEmuHk.
  All other shells must report the start of the prompt with ANSI.


  For example, while using bash and connector you may add to the end
  of your `PS1` the following sequence: `\[\033]9;12\007\]`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants