-
Notifications
You must be signed in to change notification settings - Fork 148
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
oh my posh theme lambdageneration.omp.json draws wrongly in Chinese codepage 936 (Simplified Chinese) #406
Comments
i write |
What is the output from What is the full output from |
clink set
|
chcp 936 |
if I use clink below 1.4.9,this problem won't appear. |
What font are you using? Is there a link where I can download it? This has to be due to the East Asian ambiguous character width fix. I want to test with the same font you're using, to see if it's a font issue, or terminal issue, or OS issue, or Clink issue. And hopefully I can find an automatic workaround. In the meantime, you can probably get it working by changing the And I just noticed the online documentation refers to inaccurate names for the available modes, so refer to |
The fancy line drawing characters are in the range of East Asian ambiguous width characters. Different terminals will draw and measure them differently, and may or may not match how the OS measures them in the hidden "real" console window that contains the underlying text and layout which terminal programs then draw into a visible window.
So it's indeed the classic problem caused by the East Asian ambiguous width characters. In recent versions of Clink, when you press Ctrl-X,Ctrl-Z it will analyze the prompt text, report characters that may be problematic, and offer suggestions for how to resolve problems that might occur. And in CJK codepages (including 936) it reports several ambiguous width characters in the prompt text when using the You'll need to either use P.S. The reason that the default |
... but also, the lambdageneration.omp.json theme is actually printing Unicode codepoint 0xFB26 which is the Hebrew letter Wide Final Mem |
@andywowws I think I found a solution that will make it work automatically again, at least in most cases. I'll finish testing it today and probably publish a new version later today. |
I'm using Anonymice nerd font |
Have you upgraded to v1.4.11 yet? |
yes,and it fixed! |
But it only works in code page 65001 |
@andywowws Ok, but then no, you're saying the CJK ambiguous width problems aren't fixed at all, then, for you. Codepage 65001 is not a CJK codepage, it is UTF8. I was able to reproduce the CJK issue using the steps you provided. I tracked it down and fixed it, and verified it no longer occurs in v1.4.11 with any of the four CJK codepages. v1.4.11 also includes new logging about the East Asian ambiguous width character measurements. Can you please:
|
ok
clink set
|
@andywowws Unfortunately, that clink.log file is essentially empty, and is from a different session. It looks like you've got AutoRun enabled, and so running oh-my-posh also runs another CMD, which tries to AutoRun-inject Clink, which resets the log file. Try the following, to capture the needed log info:
In the meantime, I'll see if I can come up with a way for AutoRun during prompt filtering to not zap log files. Depending on what the log file reveals, I also might need to add more logging. |
I confirm that the bug still happens
|
Wait a minute |
i found that east_asian_ambiguous can't automatically solve this problem but if I set east_asian_ambiguous to one the bug will be fixed |
i've run |
@andywowws the log file is still missing the needed info. Are you willing to install a pre-release version of Clink with extra logging and extra logic? If so, that would make it easy to get the needed info. (It will even automatically upgrade to the next official release.) |
ok |
Unfortunatelly the log is still too short |
"pre-release" didn't mean an old released version. I meant would you be willing to run a new and unreleased version that I haven't released yet, where the logging has been changed to produce more information. Here is the new pre-release version: clink.1.4.12.802320.zip |
okay |
i'll try it soon |
clink.log
|
The'新宋体' is a font that have been intergrated into Microsoft Office,and it's use to desplay chinese characters |
Aha! That explains it. Somehow that font has become selected as the default console font from the OS's perspective, and that font draws those as double-width characters. I don't know how to change what font the OS thinks is being used (it isn't done by changing the font in the Properties page of a console window). Unfortunately there is no way for a console program to find out what font will be used by a terminal program. There is only a way to ask the OS what the default conhost terminal thinks the font would be. That's what Clink uses in the I could maybe add a setting that could be used to tell Clink what font to expect. But it would still be easy for that to be out of sync with the actual font, and it still isn't automatic. I can't see any way to make this automatically work "properly" in CJK codepages. The only ways I know to get it to work properly are to use |
You stated that powershell7 works correctly. But I'll try to see if I can test that (it might be difficult since I don't have Windows installed using Simplified Chinese, and I wouldn't be able to read anything if i did). And I'll try to see if the powershell7 public source code is doing something special that I can learn from. |
Wish this annoying bug could be fixed soon. |
@andywowws Ugh. I've looked at what the PowerShell/PSReadLine library does. I see why PowerShell "works":
And sure enough, as expected, it turns out to be pretty easy to get PowerShell's input line display to malfunction when using any of the four CJK codepages.
So, while PowerShell may give the perception that it works in CJK codepages, it's pretty easy to get it to have the same kinds of problems that Clink has (and also some problems that Clink doesn't have). I cannot make Clink do exactly the same thing PSReadLine does; it would break many Clink capabilities that PowerShell doesn't have (and therefore doesn't have to support). However, I can add the following hack when using any of the 4 CJK codepages. This should make it behave like PowerShell does, except while resizing the terminal:
The display won't be fully reliable in some edge cases. But it will be similarly reliable as PowerShell's display. So if the perception is that PowerShell works properly, then probably the perception will also be that the hack makes Clink work properly. |
@andywowws Making it automatically go away for everyone in all possible cases is a much, much, much harder problem to solve. But I'm working on getting it as close to that as possible. |
(Also, the technique used by PowerShell can fail if the prompt is exactly the width of the terminal. That's uncommon, but people have reported exactly that situation in Clink, and the rewrite of the prompt/input display accommodated that case. But in CJK codepages it won't be able to handle that correctly anymore, just like PowerShell isn't able to handle it correctly.) |
@andywowws Can you please try this new prototype version? Please also run The improvements
Tested casesThese improvements make the prompt and input line work for me in the following cases:
Various combinations of terminal programs and fonts draw the prompt text slightly differently, but Clink is able to make the cursor position consistently match what was drawn by the terminal program. The "Tabby" terminal program draws the text using one set of measurements, and positions the cursor using a different set of measurements. It malfunctions with CMD.exe by itself, and also with Clink. It is clearly due to bugs in "Tabby" itself, not CMD.exe or Clink. Also, I have found and reproduced many different cases where PowerShell malfunctions and draws the prompt or input line incorrectly. Clink has only a couple of the same problems, which are simply not fixable in either program (PowerShell or Clink) with the current console APIs in Windows. As far as I can tell in my testing, Clink is now more reliable than PowerShell when displaying prompt text and input line text when using CJK code pages (and PowerShell completely fails to handle ambiguous width characters in CJK code pages when using conhost as the terminal, but Clink works as expected in that case). |
ohhhh,finally it works! |
Excellent. Thank you for reporting the issue and for your timely responses and helping to find and verify a fix; I appreciate it very much. I expect to publish an update with the fix probably later tonight. |
After Update Clink to the latest version,it doesn't work well with oh-my-posh
The text was updated successfully, but these errors were encountered: