Skip to content

PSReadline causes Ø to be displayed as O in Powershell #1010

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

Closed
HaraldKorneliussen opened this issue Aug 26, 2019 · 2 comments
Closed

PSReadline causes Ø to be displayed as O in Powershell #1010

HaraldKorneliussen opened this issue Aug 26, 2019 · 2 comments

Comments

@HaraldKorneliussen
Copy link

When using a Norwegian keyboard layout, and writing the letter ø, it shows as an o. It still IS an ø, for instance if you write

echo "bo" <--- really write bø

you get back

Stripping diacritics, even for display purposes, is never a good internationalization solution. For Norwegian it can turn a common word like "høre" (to listen) into a nasty slur.

This bug was previously reported here:

https://github.com/microsoft/terminal/issues/308 

but was apparently never passed on to here, and is still present.

Since the error disappears when

Remove-Module PSReadline

is run, it seems to be this module which causes the problem. See the linked issue for more discussion about what happens.

Environment data

PS version: 5.1.17763.592
PSReadline version: 2.0.0-beta2
os: 10.0.17763.1 (WinBuild.160101.0800)
PS file version: 10.0.17763.1 (WinBuild.160101.0800)
BufferWidth: 119
BufferHeight: 3000

Steps to reproduce

Change keyboard layout to Norwegian, use on-screen keyboard to write "echo ø". Watch it display echo o, but return and display ø when run.

@HaraldKorneliussen
Copy link
Author

I tried upgrading to 2.0.0-beta4 to see if the error is still present, and accidentally downgraded to 1.2. I can at least confirm the error is not present there.

@HaraldKorneliussen
Copy link
Author

With a correct upgrade to 2.0.0-beta4, I can confirm the error is not there. So it looks like this has been accidentally fixed as part of some broader issue, maybe with #768 (Fix init for non-US keyboards)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant