Conemu: Pasting / Resizing window sometimes breaks / strips / limits the command line

Created on 26 Apr 2017 · 23Comments · Source: Maximus5/ConEmu

Versions

ConEmu build: 161206 x64
OS version: Windows 10 x64
Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): bash

Problem description

Sometimes when I paste something, the command line gets limited and when it hits the limit, it starts from left.

Steps to reproduce

I sadly have no clue how to reproduce this, since this only happens sometimes and I didn't find out why yet.

Actual results

actual

Expected results

expected

Source

Morgy93

Most helpful comment

OK, I got some time to look at this and figured a few things out.

The issue where when you resize the ConEmu window, the bash command line ends up wrapping early or no longer being aligned with the window frame. This appears to be the primary issue described above.

This manifested itself mainly as the Bash input line redrawing on top of itself. It would make it some/most of the way across the window, then the cursor would carriage return onto the beginning of the same line and start drawing on top of itself.
This one had no real work around other than resizing the window back to the size it originally was, so I made a fix for it.
It turned out that we weren't sending enough messages to the WSL subsystem to let it know that the window and buffer were being updated and it needed to relay that information into the WSL environment. That means you could get into a scenario where Bash inside WSL environment was told that the buffer changed, but not that the window changed (or vice versa) and it would wrap early or late and emit the wrong VT sequences for what it was trying to do.
This fix should be coming to Insiders builds in the next few weeks and has been encompassed in the 12092729 bug I generated above for investigation.

The issue where when you have a Bash input line full of stuff, you resize the window with Word Wrap/Reflow resize on (in the "real console") and suddenly the Bash line is reprinted above/below where you expect it, sometimes leaving extraneous characters behind.
This one seems to be because Bash doesn't expect the terminal to reflow text in the way that we do. It repaints its entire prompt line and everything you wrote on it after every change/modification. If the reflow moved it to another line because there was space, it can break some of Bash's assumptions and it will then repaint strangely and differently.
The workaround to this one is to just clear the screen after reflowing or disabling reflowing in the real console. Everything should be fine from there on out.
One of my co-workers has a long term task filed to investigate if we can make Bash and other utilities like this play nicer with the Word Wrap/Reflow resize, but that's not a simple bug fix like part 1 above (we never considered that in our original design, so we'll have to go do some experiments and potentially go back to the drawing board.)

Thanks for your patience with this and thank you for reporting this issue!
--Michael

miniksa on 9 Jun 2017

👍3 ❤2 🎉2

All 23 comments

Do you use connector? If you don't, you shall report the problem to Microsoft.

Maximus5 on 26 Apr 2017

I was not able to reproduce this in bash itself yet.
Either it seems to happen while I'm ssh connected to another server or it's one of my start parameters:

"C:\Program Files\ConEmu\ConEmu64.exe" -Reuse -run {bash} -c "ssh !U@!@ -p !# -t 'cd \"!/\" ; /bin/bash'" -new_console:p:t:"!N"

I'll try to investigate it further and report back.

Morgy93 on 26 Apr 2017

Am having the same issue when starting NodeJS in command prompt when SSH'ed to OpenShift with rhc.

jerone on 26 Apr 2017

Reveal the RealConsole, set focus into it and try to paste there.

Maximus5 on 26 Apr 2017

@Maximus5 The "RealConsole" actually fixes it.
It seems that sometimes (after pasting?) .. for whatever reason .. the RealConsole window gets resized, while ConEmu stays in position - causing this weird issue @jerone and me are facing.

Morgy93 on 27 Apr 2017

Have a look at this:
orig

But I am not able to reproduce this within Bash on Ubuntu on Windows:
cur

Morgy93 on 27 Apr 2017

You must be sure ALL real console properties are THE SAME in both windows.

Maximus5 on 3 May 2017

This also happens (sometimes?) while I drag the fullscreen conemu from one monitor to another (which gets resized during movement)
I am not able to reproduce this in the real console then.

This issue is confusing and frustrating at the same time. =(

Morgy93 on 19 May 2017

Happens? Do you mean the pasting problem appears after you drag the ConEmu between monitors?

To summarize:

When you run bash.exe (WSL) in ConEmu without connector
and run ssh there to some third machine
sometimes the pasting long lines into the bash/ssh prompt do not do CR, right?

Few more questions. If the problem occurs:

In "Terminal modes" status bar column there is "BrPaste" option. Try to change it. Any changes?
In ConEmu the Paste is working like simply "typing". So, the problem have to be occurred when you just hold a key to type long sequence. Isn't it?
If you show in the time RealConsole, put focus in it and host a key, does the problem reproduces?
In RealConsole properties there is an option "Use legacy console" (https://github.com/Maximus5/ConEmu/issues/1111#issuecomment-294752049). You shall restart console to apply it. Any changes?

@miniksa I think the problem is inside conhost. Can you check that?

Maximus5 on 19 May 2017

I don't really understand the steps to reproduce this. If you can get a reliable set of steps, I can log a bug internally and try to figure it out.

miniksa on 20 May 2017

No it's not all about the pasting stuff, I am able to reproduce without pasting at all.
I'll just look for a way to be 100% reproducible and get back to you.
Give me some time =)

Morgy93 on 22 May 2017

At the moment I am able to reproduce this while only resizing the main window:
conemu
Bash on Ubuntu on Windows shows some similar issue, but not quite the same:
bash
It kinda overwrites some previous lines, but it's not quite the same as while using ConEmu.

@miniksa fyi =)

Morgy93 on 22 May 2017

I can reproduce this on my box with your steps without using ConEmu. Tried it out this morning. But oddly this only happens with the Bash window. I wonder if the shell inside the WSL environment is getting the "window resize" message and moving the cursor in response causing us to draw in the wrong spot. I can't get it to repro in CMD or Powershell. I'll have to attach a debugger to find out.

I filed MSFT: 12092729 internally for investigation. With the Windows Insider Bug Bash last week, we have a high volume of bugs right now. It might take up to a few weeks for me to get time to investigate this.

miniksa on 22 May 2017

👍1

The difference may be in the API which the shell is using.
Bash (doesn't matter WSL or msys/cygwin) reads keypresses one-by-one. But cmd uses ReadConsole which does not return to user mode until Enter.

Maximus5 on 23 May 2017

OK, I got some time to look at this and figured a few things out.

The issue where when you resize the ConEmu window, the bash command line ends up wrapping early or no longer being aligned with the window frame. This appears to be the primary issue described above.

This manifested itself mainly as the Bash input line redrawing on top of itself. It would make it some/most of the way across the window, then the cursor would carriage return onto the beginning of the same line and start drawing on top of itself.
This one had no real work around other than resizing the window back to the size it originally was, so I made a fix for it.
It turned out that we weren't sending enough messages to the WSL subsystem to let it know that the window and buffer were being updated and it needed to relay that information into the WSL environment. That means you could get into a scenario where Bash inside WSL environment was told that the buffer changed, but not that the window changed (or vice versa) and it would wrap early or late and emit the wrong VT sequences for what it was trying to do.
This fix should be coming to Insiders builds in the next few weeks and has been encompassed in the 12092729 bug I generated above for investigation.

The issue where when you have a Bash input line full of stuff, you resize the window with Word Wrap/Reflow resize on (in the "real console") and suddenly the Bash line is reprinted above/below where you expect it, sometimes leaving extraneous characters behind.
This one seems to be because Bash doesn't expect the terminal to reflow text in the way that we do. It repaints its entire prompt line and everything you wrote on it after every change/modification. If the reflow moved it to another line because there was space, it can break some of Bash's assumptions and it will then repaint strangely and differently.
The workaround to this one is to just clear the screen after reflowing or disabling reflowing in the real console. Everything should be fine from there on out.
One of my co-workers has a long term task filed to investigate if we can make Bash and other utilities like this play nicer with the Word Wrap/Reflow resize, but that's not a simple bug fix like part 1 above (we never considered that in our original design, so we'll have to go do some experiments and potentially go back to the drawing board.)

Thanks for your patience with this and thank you for reporting this issue!
--Michael

miniksa on 9 Jun 2017

👍3 ❤2 🎉2

Thanks, Michael!

Is there a way to disable reflowing from ConEmu? It's nice to retail upper buffer contents, which is irreversible cropped otherwise, but it cause problems.
As an alternative, I think about software reflowing implemented by ConEmu or reflowing only invisible part of the buffer.

Maximus5 on 10 Jun 2017

Hi Maximus,

There's not currently a way to programmatically adjust the reflowing setting. You can adjust it with the LineWrap REG_DWORD key under HKCU console before starting a console session (for those that load from the registry), or you can UI automate it off the property sheet... but there's no API or anything nice like that right now. :(

We have some people trying to figure out a comprehensive update to our settings story and exposing the difficult-to-set-settings is one of the things included in it, but I have no promises on timeline.

Sorry it's so obtuse. You might have to resort to a creative workaround in the meantime.

Thanks,
--Michael

miniksa on 12 Jun 2017

Hi,

It looks like fix is already there:
https://github.com/Microsoft/BashOnWindows/issues/1001

But this is still reproducible in 100% of time for me.

nick4fake on 13 Jul 2017

👍2

I would also like to note that cmd and PowerShell are ok - resizing works as expected.

nick4fake on 13 Jul 2017

I had this happen to me because of something completely unrelated. This might not help but if your setting your PS1-PS4 make sure any non-printable characters (like color changes ) are surounded with \[ and \]. Hope this isn't just useless spam.