Terminal: erratic cursor and display in emacs

[christianpaquin]

This bug-tracker is monitored by Windows Console development team and other technical types. We like detail!

If you have a feature request, please post to the UserVoice.

Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues. Instead, send dumps/traces to [email protected], referencing this GitHub issue.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.17763.1]
  Windows 10, version 1809 installed on Oct 4, 2018.

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

1. I installed Ubuntu 18.04 from the Windows Store, and "sudo apt-get emacs" (v25.2.2 was installed)
2. open a file larger than the console height (I used a large C file)
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)

• What's wrong / what should be happening instead:
  The cursor becomes erratic and the display gets garbled after moving the cursor and moving down the file. This started happening after the 1809 update.

PS: this seems to be the same behavior as in WSL's issue 3587

[Erebuxy]

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?

[christianpaquin]

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)

[Erebuxy]

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.

[zadjii-msft]

1. 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)
2. 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.

[christianpaquin]

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.

[uhengart]

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.

[zadjii-msft]

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]

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.

[PgAuffret]

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

[miniksa]

Probably early to mid January in Insiders builds.

[PgAuffret]

Thank you :)

[mgennari]

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.

[miniksa]

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.

[mgennari]

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.

[bubbleguuum]

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

[miniksa]

This is fixed in Insiders 18309 and higher.

[lafredin]

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.

[DHowett-MSFT]

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!

[lafredin]

@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

[bubbleguuum]

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.

[PgAuffret]

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

[zadjii-msft]

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

[saraheno]

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

[zadjii-msft]

@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.

[Steven-Wright]

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

[mathieufortin01]

:point_up: :point_up: this is the temporary workaround that works.

[saraheno]

Thank you!

On Wed, Mar 13, 2019 at 8:42 AM Mathieu Fortin [e-mail]
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
.

[thcoffee-msft]

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.

[quarkgluons]

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.

[diracyoon]

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

[zadjii-msft]

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.

[zendevil]

We are still waiting for the fix.

[Summon528]

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

[diracyoon]

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

[zadjii-msft]

@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.

[thcoffee-msft]

After upgrading to 1903, I find that Emacs remains unusable with the default TERM=xterm-256color. Here's an example with screenshots for illustration:

1. Start WSL Debian, enter emacs -q -nw, open file larger than console (example: C-x C-f .bashrc). So far so good:

1. Search for text beyond the end of the console (example for my .bashrc: C-s gu). Text begins to be shuffled:

1. Continuing search text entry (in this example, extending "gu" to "gurob"), there's additional shuffling:

1. Here's the text that appears when attempting to scroll to the end of the file. Different bits are shuffled instead:

1. For reference, here's what the actual end of the file looks like:

This is the easiest example I could construct, but the shuffling behavior is pervasive. Almost anytime Emacs is rewriting irregular portions of the terminal, text may be shifted from places it previously appeared into areas where no text should appear. Once spurious text is on the loose, it generally persists through scrolling until overwritten, eventually leading files to appear as a soup of text fragments. And any features that rely on dynamically resizing multiple buffers (such as the minibuffer) are nearly hopeless to use, as lines don't even appear in the right places.

I haven't identified a precise pattern to explain the observed behavior, but I'm sure that anyone who attempts to make any substantial use of Emacs on WSL will encounter these bizarre effects. They make it impossible to do any work in console Emacs without downgrading the terminal to, e.g., rxvt, which is substantially inferior in color and keyboard support.

[thcoffee-msft]

Thanks to https://github.com/microsoft/terminal/issues/1474#issuecomment-504765389 from @sandric, I've found that tmux resolves these issues, so I will probably use this workaround for the time being.

[sandric]

@thcoffee-msft actually that is pretty strange advice meaning name of repo, though, I found that smth like multiple-cursors still working with glitches no matter how I tried in new term preview, so my humble suggestion to other emacs guys like me - switch to wsltty for now, latest updates works with WSL2 via standard windows console, and it works flawlessly for me.

[mhairifin]

If other people are still experiencing problems, so far TERM=konsole has produced the least issues for me

[kiyoMatsui]

Edit: This isn't true anymore :| mhairifin is again correct, it makes emacs just about workable, certainly less issues than before. Sorry all should have just waited a day... i was overly excited!

Thanks mhairifin, you have saved me from zile purgatory.
For those who just want things to work. add: TERM=konsole
at the end of your .bashrc file and it j̶u̶s̶t̶ ̶w̶o̶r̶k̶s̶!̶

[calbaker]

Adding export TERM=rxvt to my ~/.bashrc file worked great. You can also run this command in terminal to test it out. Adding it to ~/.bashrc will be persistent.

[thcoffee-msft]

Just to update the thread, the workflow that continues to resolve all these problems for me (and avoids the color downgrade of rxvt) is something like:

1. tmux
2. export TERM=xterm-256color
3. emacs -nw

The only annoyance of using emacs through tmux is that tmux binds C-b as a prefix key by default, which can be resolved by binding a different key in ~/.tmux.conf, such as:

unbind C-b
set-option -g prefix M-'\'

[PieterPaulussen]

Having similar issues with suckless st's terminal... Sigh