erratic cursor and display in emacs #418

@bn-d commented on GitHub (Oct 13, 2018):

Have the same problem here in Vim, Tmux etc. after recent Window 10 Pro insider preview update (Ver 1809 Build 10.0.18252.1000).
I think a simple fix is to stop the cursor blinking. Is there any way to do that?

@bn-d commented on GitHub (Oct 13, 2018): Have the same problem here in Vim, Tmux etc. after recent Window 10 Pro insider preview update (Ver 1809 Build 10.0.18252.1000). I think a simple fix is to stop the cursor blinking. Is there any way to do that?

claunia commented

@christianpaquin commented on GitHub (Oct 13, 2018):

I think a simple fix is to stop the cursor blinking. Is there any way to do that?

I experience the same problem if I start emacs with no blinking cursor (-nbc)

@christianpaquin commented on GitHub (Oct 13, 2018): > I think a simple fix is to stop the cursor blinking. Is there any way to do that? I experience the same problem if I start emacs with no blinking cursor (-nbc)

claunia commented

@bn-d commented on GitHub (Oct 14, 2018):

I think a simple fix is to stop the cursor blinking. Is there any way to do that?

I experience the same problem if I start emacs with no blinking cursor (-nbc)

I believe this is the same as Microsoft/console#269.

@bn-d commented on GitHub (Oct 14, 2018): > > I think a simple fix is to stop the cursor blinking. Is there any way to do that? > > I experience the same problem if I start emacs with no blinking cursor (-nbc) I believe this is the same as Microsoft/console#269.

claunia commented

@zadjii-msft commented on GitHub (Oct 15, 2018):

start moving the cursor using alt-f (to move forward word to word); at some point the cursor visually jumps at the end of line but actually remains where it is supposed to be (hitting ctrl-l to re-center the screen around the current line refreshed the screen correctly)

when editing the text, the display gets garbled, the letters appearing on subsequent lines. This only affects the buffer visually, the logical buffer is ok ((hitting ctrl-l to re-center the screen around the current line refreshed the screen correctly)

These two are what makes me think it's different than #269. My gut tells me that there's something new in 18.04's termcap that we don't support yet.
I've filed MSFT:19302368 internally to make sure this gets looked at.

@zadjii-msft commented on GitHub (Oct 15, 2018): > 3. start moving the cursor using alt-f (to move forward word to word); at some point the cursor visually jumps at the end of line but actually remains where it is supposed to be (hitting ctrl-l to re-center the screen around the current line refreshed the screen correctly) > 4. when editing the text, the display gets garbled, the letters appearing on subsequent lines. This only affects the buffer visually, the logical buffer is ok ((hitting ctrl-l to re-center the screen around the current line refreshed the screen correctly) These two are what makes me think it's different than #269. My gut tells me that there's something new in 18.04's termcap that we don't support yet. I've filed MSFT:19302368 internally to make sure this gets looked at.

claunia commented

@christianpaquin commented on GitHub (Oct 15, 2018):

My gut tells me that there's something new in 18.04's termcap that we don't support yet.

FYI, I experience the same thing in my original "Bash on Ubuntu on Windows" install; I tried installing the 18.04 store app (and documented it as such in the repro steps) to see if I had the same problem.

@christianpaquin commented on GitHub (Oct 15, 2018): > My gut tells me that there's something new in 18.04's termcap that we don't support yet. FYI, I experience the same thing in my original "Bash on Ubuntu on Windows" install; I tried installing the 18.04 store app (and documented it as such in the repro steps) to see if I had the same problem.

claunia commented

@uhengart commented on GitHub (Oct 16, 2018):

I'm also observing this problem. However, I don't think it's tied to Ubuntu 18.04. The problem started occurring after the W10 1809 upgrade while still running Ubuntu 16.04 in WSL.

I just upgraded Ubuntu 16.04 in WSL to 18.04 on a second machine, which hasn't been upgraded to W10 1809. The problem doesn't occur there for either version of Ubuntu.

@uhengart commented on GitHub (Oct 16, 2018): I'm also observing this problem. However, I don't think it's tied to Ubuntu 18.04. The problem started occurring after the W10 1809 upgrade while still running Ubuntu 16.04 in WSL. I just upgraded Ubuntu 16.04 in WSL to 18.04 on a second machine, which hasn't been upgraded to W10 1809. The problem doesn't occur there for either version of Ubuntu.

claunia commented

@zadjii-msft commented on GitHub (Nov 26, 2018):

I think I have a beat on the change that broke this. I believe it has to do with the tab stops. I know emacs will sometime use tab to advance the cursor to the next tab-stop, instead of positioning the cursor manually. It seems like there's some scenario where the tab stops aren't properly getting set, which means instead of the cursor moving to the next tab stop (usually every 8 columns), the console is moving the cursor to the end of the line. It's this disconnect between where emacs believes the cursor is and where the cursor actually is that's causing these problems.

Theoretically, a TERM setting that doesn't use the tabstops should fix this, though I don't know which setting would be most appropriate, or exactly which sequence is broken currently. It's probably a combination of tbc and hts.

I don't have a fix yet, but I'll keep this thread posted with updates.

@zadjii-msft commented on GitHub (Nov 26, 2018): I think I have a beat on the change that broke this. I believe it has to do with the tab stops. I know emacs will sometime use tab to advance the cursor to the next tab-stop, instead of positioning the cursor manually. It seems like there's some scenario where the tab stops aren't properly getting set, which means instead of the cursor moving to the next tab stop (usually every 8 columns), the console is moving the cursor to the end of the line. It's this disconnect between where emacs believes the cursor is and where the cursor actually is that's causing these problems. Theoretically, a `TERM` setting that doesn't use the tabstops should fix this, though I don't know which setting would be most appropriate, or exactly which sequence is broken currently. It's probably a combination of `tbc` and `hts`. I don't have a fix yet, but I'll keep this thread posted with updates.

claunia commented

@zadjii-msft commented on GitHub (Dec 4, 2018):

Okay, so I am fairly sure I found the source of this. In RS5 during the course of other tab-stop fixes, we forgot to setup the default tabstop positions on the alt buffer. The fix is really simple, so once I get a test on it, it should be on it's way to Insider's soon.

@zadjii-msft commented on GitHub (Dec 4, 2018): Okay, so I am fairly sure I found the source of this. In RS5 during the course of other tab-stop fixes, we forgot to setup the default tabstop positions on the alt buffer. The fix is really simple, so once I get a test on it, it should be on it's way to Insider's soon.

claunia commented

@PgAuffret commented on GitHub (Dec 20, 2018):

Hello,
Issue may be reproduced using Emacs. Please find attached a captured sequence.
Any idea when this will be solved ?
Thank you

Windows console emulator: ConEmu-Maximus5
Distrib: Ubuntu 1804.2018.817.0
OS : Windows 10 Pro 1809, 17763.195

emac_cursor_issue.zip

@PgAuffret commented on GitHub (Dec 20, 2018): Hello, Issue may be reproduced using Emacs. Please find attached a captured sequence. Any idea when this will be solved ? Thank you > Windows console emulator: ConEmu-Maximus5 > Distrib: Ubuntu 1804.2018.817.0 > OS : Windows 10 Pro 1809, 17763.195 ![emac_cursor_issue](https://user-images.githubusercontent.com/11138527/50279344-b4907300-0449-11e9-804e-b209f268ea33.gif) [emac_cursor_issue.zip](https://github.com/Microsoft/console/files/2698430/emac_cursor_issue.zip)

claunia commented

@miniksa commented on GitHub (Dec 20, 2018):

Probably early to mid January in Insiders builds.

@miniksa commented on GitHub (Dec 20, 2018): Probably early to mid January in Insiders builds.

claunia commented

@PgAuffret commented on GitHub (Dec 21, 2018):

Thank you :)

@PgAuffret commented on GitHub (Dec 21, 2018): Thank you :)

claunia commented

@mgennari commented on GitHub (Jan 2, 2019):

While it is suggested that an early to mid January fix would be inbound in the Insiders build, what might the timeline look like for a Windows 1809 fix?

Note:
For those afflicted with this issue, I reccomend setting TERM to xterm-color as this improves the behaviour drastically, however it is still dysfunctional.

@mgennari commented on GitHub (Jan 2, 2019): While it is suggested that an early to mid January fix would be inbound in the Insiders build, what might the timeline look like for a Windows 1809 fix? Note: For those afflicted with this issue, I reccomend setting TERM to xterm-color as this improves the behaviour drastically, however it is still dysfunctional.

claunia commented

@miniksa commented on GitHub (Jan 2, 2019):

By default, we don't port things back to Windows builds that have already RTM'd unless they're causing a security issue, significant end-user impact, or have some other business justification. Servicing a released OS is not free, so it's generally limited to what's absolutely necessary.

@miniksa commented on GitHub (Jan 2, 2019): By default, we don't port things back to Windows builds that have already RTM'd unless they're causing a security issue, significant end-user impact, or have some other business justification. Servicing a released OS is not free, so it's generally limited to what's absolutely necessary.

claunia commented

@mgennari commented on GitHub (Jan 2, 2019):

Thank you for the information! Will any information about a fix be made public such that we can implement it ourselves? I rely on the functionality pretty heavily for research work, so any improvements are welcomed.

@mgennari commented on GitHub (Jan 2, 2019): Thank you for the information! Will any information about a fix be made public such that we can implement it ourselves? I rely on the functionality pretty heavily for research work, so any improvements are welcomed.

claunia commented

@bubbleguuum commented on GitHub (Jan 3, 2019):

Is there any workaround on 1809 for this annoying bug until a fixed WSL is available ? This makes emacs entirely unusable.

@bubbleguuum commented on GitHub (Jan 3, 2019): Is there any workaround on 1809 for this annoying bug until a fixed WSL is available ? This makes emacs entirely unusable.

claunia commented

@miniksa commented on GitHub (Jan 18, 2019):

This is fixed in Insiders 18309 and higher.

@miniksa commented on GitHub (Jan 18, 2019): This is fixed in Insiders 18309 and higher.

claunia commented

@lafredin commented on GitHub (Feb 15, 2019):

Is this seriously not going to be fixed in the regular build? My company settings don't allow me to use Insiders and this is making Linux practically unusable.

@lafredin commented on GitHub (Feb 15, 2019): Is this seriously not going to be fixed in the regular build? My company settings don't allow me to use Insiders and this is making Linux practically unusable.

claunia commented

@DHowett-MSFT commented on GitHub (Feb 15, 2019):

Hi @lafredin,
We haven't been able to build up a compelling case (that is: one that provably impacts a business's ability to ship Windows or for an enterprise to onboard their users) to start the servicing pipeline to take this bugfix downlevel. Really sorry about that!

@DHowett-MSFT commented on GitHub (Feb 15, 2019): Hi @lafredin, We haven't been able to build up a compelling case (that is: one that provably impacts a business's ability to ship Windows or for an enterprise to onboard their users) to start the servicing pipeline to take this bugfix downlevel. Really sorry about that!

claunia commented

@lafredin commented on GitHub (Feb 15, 2019):

@DHowett-MSFT this is a serious usability issue though. It has been around for months and has a known fix. Honestly emacs is completely unusable with the cursor and line skipping. The whole idea of WSL was to give a usable Linux environment natively on a Windows computer to not force people to use clunky 3rd party options or VMs or switch to a Mac...not updating non-Insiders' user experience seems totally counter to this

@lafredin commented on GitHub (Feb 15, 2019): @DHowett-MSFT this is a serious usability issue though. It has been around for months and has a known fix. Honestly emacs is completely unusable with the cursor and line skipping. The whole idea of WSL was to give a usable Linux environment natively on a Windows computer to not force people to use clunky 3rd party options or VMs or switch to a Mac...not updating non-Insiders' user experience seems totally counter to this

claunia commented

@bubbleguuum commented on GitHub (Feb 15, 2019):

It's unfortunate that this issue cannot be hotfixed in current version of Windows, especially since it was not an issue in 1803. Among other issues with WSL (notably slow I/O, Console not supporting tabs), this is what made me switch recently to full blown Linux for development...Other than that, WSL is a great project and I have no doubt it will get even better.

@bubbleguuum commented on GitHub (Feb 15, 2019): It's unfortunate that this issue cannot be hotfixed in current version of Windows, especially since it was not an issue in 1803. Among other issues with WSL (notably slow I/O, Console not supporting tabs), this is what made me switch recently to full blown Linux for development...Other than that, WSL is a great project and I have no doubt it will get even better.

claunia commented

@PgAuffret commented on GitHub (Feb 18, 2019):

Hi,
I'm not quite sure to understand. Will the next regular update fix it?
Thank you

@PgAuffret commented on GitHub (Feb 18, 2019): Hi, I'm not quite sure to understand. Will the next regular update fix it? Thank you

claunia commented

@zadjii-msft commented on GitHub (Feb 19, 2019):

@PgAuffret Yes, whatever the next version of Windows after 1809 is will contain the fix for this issue.

@zadjii-msft commented on GitHub (Feb 19, 2019): @PgAuffret Yes, whatever the next version of Windows after 1809 is will contain the fix for this issue.

claunia commented

@saraheno commented on GitHub (Mar 2, 2019):

I am currently having this problem. Windows tells me it is version 10.0.17763 build 17763. Which of these digits would correspond to 1809? Also, Windows tells me it is up to date, so I assume this is after 1809?

Okay, I do have 1809. I downloaded ubuntu from the microsoft store on 2 March 2019. I did

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get install emacs

I then do emacs -nw aaa_readme.txt and type
123456 and then the space key.

The curser goes to the end of the screen as shown

@saraheno commented on GitHub (Mar 2, 2019): I am currently having this problem. Windows tells me it is version 10.0.17763 build 17763. Which of these digits would correspond to 1809? Also, Windows tells me it is up to date, so I assume this is after 1809? Okay, I do have 1809. I downloaded ubuntu from the microsoft store on 2 March 2019. I did sudo apt-get update sudo apt-get upgrade sudo apt-get dist-upgrade sudo apt-get install emacs I then do emacs -nw aaa_readme.txt and type 123456 and then the space key. The curser goes to the end of the screen as shown ![a0b67c66-7bea-4479-b32a-683602ac3ab3 png](https://user-images.githubusercontent.com/5215288/53688587-0db33780-3d14-11e9-8a6c-65dd146bf4d7.jpg)

claunia commented

@zadjii-msft commented on GitHub (Mar 5, 2019):

@saraheno Unfortunately Windows' naming scheme is super confusing, so hopefully this chart will clear things up:

(see wikipedia)

Version 1809 is build 17763.*

Anything that's version 1809 will have this bug.

The fix is available in Insiders builds of 19H1, which doesn't yet have an official version or build number. Any Insider's builds above 10.0.18309 will have the fix.

@zadjii-msft commented on GitHub (Mar 5, 2019): @saraheno Unfortunately Windows' naming scheme is super confusing, so hopefully this chart will clear things up: ![image](https://user-images.githubusercontent.com/18356694/53821149-0a8d9680-3f22-11e9-991c-340e098884ce.png) (see [wikipedia](https://en.wikipedia.org/wiki/Windows_10_version_history)) Version 1809 is build 17763.* Anything that's version 1809 will have this bug. The fix is available in Insiders builds of 19H1, which doesn't yet have an official version or build number. Any Insider's builds above 10.0.18309 will have the fix.

claunia commented

@Steven-Wright commented on GitHub (Mar 7, 2019):

setting TERM to vt100 sufficed to get the basic emacs navigation working (C-f, Alt-f, etc.)

@Steven-Wright commented on GitHub (Mar 7, 2019): setting TERM to vt100 sufficed to get the basic emacs navigation working (C-f, Alt-f, etc.)

claunia commented

@mathieufortin01 commented on GitHub (Mar 13, 2019):

☝️ ☝️ this is the temporary workaround that works.

@mathieufortin01 commented on GitHub (Mar 13, 2019): :point_up: :point_up: this is the temporary workaround that works.

claunia commented

@saraheno commented on GitHub (Mar 13, 2019):

Thank you!

On Wed, Mar 13, 2019 at 8:42 AM Mathieu Fortin notifications@github.com
wrote:

☝️ ☝️ this is the temporary workaround that works.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/console/issues/283#issuecomment-472406061,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE-UODT3NqyaaOWuJ8zC9KENaMHN6PVAks5vWPI7gaJpZM4XZrw8
.

@saraheno commented on GitHub (Mar 13, 2019): Thank you! On Wed, Mar 13, 2019 at 8:42 AM Mathieu Fortin <notifications@github.com> wrote: > ☝️ ☝️ this is the temporary workaround that works. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/Microsoft/console/issues/283#issuecomment-472406061>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AE-UODT3NqyaaOWuJ8zC9KENaMHN6PVAks5vWPI7gaJpZM4XZrw8> > . >

claunia commented

@thcoffee-msft commented on GitHub (Mar 21, 2019):

For affected users, I have found that setting TERM=rxvt produces better behavior than any of the options mentioned above.

I tried this on the basis of a comparison table on Wikipedia, searching for options that supported color but not tab stops. This is clearly not the whole story, but I have very little knowledge of terminal implementations.

@thcoffee-msft commented on GitHub (Mar 21, 2019): For affected users, I have found that setting TERM=rxvt produces better behavior than any of the options mentioned above. I tried this on the basis of a [comparison table](https://en.wikipedia.org/wiki/Comparison_of_terminal_emulators) on Wikipedia, searching for options that supported color but not tab stops. This is clearly not the whole story, but I have very little knowledge of terminal implementations.

claunia commented

@quarkgluons commented on GitHub (Mar 23, 2019):

For affected users, I have found that setting TERM=rxvt produces better behavior than any of the options mentioned above.

I tried this on the basis of a comparison table on Wikipedia, searching for options that supported color but not tab stops. This is clearly not the whole story, but I have very little knowledge of terminal implementations.

This one worked for me as well.

@quarkgluons commented on GitHub (Mar 23, 2019): > For affected users, I have found that setting TERM=rxvt produces better behavior than any of the options mentioned above. > > I tried this on the basis of a [comparison table](https://en.wikipedia.org/wiki/Comparison_of_terminal_emulators) on Wikipedia, searching for options that supported color but not tab stops. This is clearly not the whole story, but I have very little knowledge of terminal implementations. This one worked for me as well.

claunia commented

@diracyoon commented on GitHub (Apr 30, 2019):

Please please fix it asap!!! WSL became effectively useless. Even with latest version of 1809 17763.437, emacs cursor doesn't work properly.

@diracyoon commented on GitHub (Apr 30, 2019): Please please fix it asap!!! WSL became effectively useless. Even with latest version of 1809 17763.437, emacs cursor doesn't work properly.

claunia commented

@zadjii-msft commented on GitHub (Apr 30, 2019):

Please read the thread before replying.

The fix is in any Insiders builds above 10.0.18309, and will ship officially with the May 2019 release, version 1903

There are a number of workarounds mentioned in the thread, including setting the TERM envvar to either rxvt or vt100.

@zadjii-msft commented on GitHub (Apr 30, 2019): Please read the thread before replying. ## The fix is in any Insiders builds above 10.0.18309, and will ship officially with the May 2019 release, version 1903 There are a number of workarounds mentioned in the thread, including setting the `TERM` envvar to either `rxvt` or `vt100`.

claunia commented

@zendevil commented on GitHub (Jun 7, 2019):

We are still waiting for the fix.

@zendevil commented on GitHub (Jun 7, 2019): We are still waiting for the fix.

claunia commented

@Summon528 commented on GitHub (Jun 7, 2019):

@zendevil Windows 10 1903 just recently released, you can get it here if you don't want to wait anymore

@Summon528 commented on GitHub (Jun 7, 2019): @zendevil Windows 10 1903 just recently released, you can get it [here](https://www.microsoft.com/software-download/windows10) if you don't want to wait anymore

claunia commented

@diracyoon commented on GitHub (Jun 21, 2019):

After update windows 10 to 1903 version, the bug became better. However still not fixed perfectly.

@diracyoon commented on GitHub (Jun 21, 2019): After update windows 10 to 1903 version, the bug became better. However still not fixed perfectly.

claunia commented

@zadjii-msft commented on GitHub (Jul 1, 2019):

@diracyoon could you file a new issue with exact repro steps and a description (preferably screenshots) of what's wrong? The specific issue described by this thread was fixed in 1903, and I'd rather have a new thread to track the new bug, even if it does have a similar symptom.

Unless of course #1474 is an exact description of the problem you're seeing.

@zadjii-msft commented on GitHub (Jul 1, 2019): @diracyoon could you file a new issue with exact repro steps and a description (preferably screenshots) of what's wrong? The specific issue described by this thread was fixed in 1903, and I'd rather have a new thread to track the new bug, even if it does have a similar symptom. **Unless of course #1474 is an exact description of the problem you're seeing.**

claunia commented