Closed HLFH closed 2 months ago
@DHowett-MSFT that's happens on CMD, PowerShell and windows new terminal .
My WSL is printing some unusual characters after it has rendered the unicode string. I was trying to build an interactive game and wasn't able to display the characters due to this. Looks like I have to restrict myself to 128-bit ASCII
I just want to say, with apologies, that this looks hilarious.
Is the src code for fmt_test.exe available somewhere? (screenshot by @fcharlie earlier in this thread) I am having hard time duplicating the result.
Thanks!
Hi, To add on the comment of @AmericanY , when pasting in the Windows Terminal an emoji (say from a preexisting output) it is broken in the input and correct in the output. Also if doing an up arrow right after, then it is correct in the input this time.
Is this expected ?
Windows Terminal Powershell Core 6.2.1 Meslo LG M for Powerline
@AmericanY yeah, this is an issue with PowerShell 5.1.
Besides that one, the space between two emojis get converted to linefeed in posh 5.1, but not in other shells like ash, bash and so on:
@remidebette You'll want to see #1503
@zadjii-msft , this seems quite hard, but will be really nice once you crack it. Hang in there!
I've tested emoji on a few shells under Windows Terminal (Version: 0.11.1191.0) and here are results:
Looks like the only shell that works perfectly so far is WSL (both bash and zsh)...
I’m working with an old set of information, but it at least used to be that the console stores the prompt line in a separate buffer from the output buffer and that it didn’t support more than ucs2 encoding. WSL works bc it’s encoded in utf8. I was working on a branch at one point that fixed this, if I find the time this weekend I’ll take a peek. Hmm
edit: WSL also might be working if it doesn't use the cooked read like the others, I don't remember if it does or not.
How can i fix the emoji?
I'm encountering the same problem; it seems no an up-to-date solution afaik.
Sweet! Another use case: I have a command line app that outputs warnings using ⚠.
Output of Emoji works fine in my experience.
So it can be sure that the problem is input characters not rendering correctly in windows terminal. I have tried Git Bash(one kind fo shell), It works well with Git Bash GUI, but not working with windows terminal same as the bugs mentioned as others.
My windows terminal version is 1.1.2233.0. Hope could fix it as soon as possible! 👍 And is there an estimated schedule?
Please file a separate bug for this issue and include the contents of your Windows Terminal settings file.
Please file a separate bug for this issue and include the contents of your Windows Terminal settings file.
I have the same issue:
{ "guid": "{00000000-0000-0000-ba54-000000000002}", "acrylicOpacity": 0.75, "closeOnExit": true, "colorScheme": "Campbell", "commandline": "\"%PROGRAMFILES%\\git\\usr\\bin\\bash.exe\" -i -l", "cursorColor": "#FFFFFF", "cursorShape": "bar", "fontFace": "Consolas", "fontSize": 10, "historySize": 9001, "icon": "%PROGRAMFILES%\\Git\\mingw64\\share\\git\\git-for-windows.ico", "name": "Bash", "padding": "10, 0", "snapOnInput": true, "startingDirectory": "%USERPROFILE%", "useAcrylic": true },
Windows Terminal: v1.3.2651.0
Git: v2.16.2.windows.1
Emoji's dont show up in an ssh session as well, not sure if you know about it.
Any update on this?
Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️
Emojis😊😋🥵 works very well on VS CODE Terminal!
Did #10478 improve this for the console? I think it did. Everything except the cooked edit line itself should probably work with the Uniscribe flows/fallback that ExtTextOutW
offers.
Is this still on the backlog? Unicode 13 was released in March 2020...
Is this still on the backlog? Unicode 13 was released in March 2020...
Seems to work for me at the moment in Windows Terminal Preview 1.12.3472.0 in both PS 5.1 and WSL2/Ubuntu, although #1472 bug (in a form of a broken Unicode sequence when using backspace) is still there.
Hey guys, is this the official thread about emoji support?
I've just tried Version: 1.15.2874.0
running a simple python script that uses rich:
from rich._emoji_codes import EMOJI
from rich.console import Console
if __name__ == "__main__":
console = Console()
for k, v in EMOJI.items():
console.print(f":{k}:")
And everything has rendered correctly on win10... Problem comes if I try to add emojis manually by pressing win+.
,
in that case I'll just get an incorrect render, ie:
Anyway, is this one already reported? Is this the right backlog work-item to suscribe to? I've read another ones pinging to this one so I'm assuming it's the "official" one... 🙄
Evolving really nicely the software btw, congrats guys!
To clarify:
This has kinda become the mega thread for both, though, most of the remaining work remains in #7777.
@zadjii-msft Hey Mike, thanks, cool stuff. So I guess the issue happening when copy/pasting emojis from other software such as SublimeText and not being rendered properly is also a related work-item from this one, ie:
You can see how in SublimeText the emojis are rendered properly, similar in the good old clipbrd.exe
software but when i copy/paste into wt
the render will be broken.
You can find the emojis.txt file attached here
Yea, basically what you're seeing is the Input version there. Pasting emoji into cmd.exe is akin to just typing an emoji at the prompt, and cmd.exe does a bad/nonexistent job of rendering those. Just outputting that file straight to the Terminal (after a chcp 65001
) does better (though, there's a LOT of emoji in that file leveraging ZWJ's, so those doen't behave super well. That's the output side of things).
It seems to me that cmd.exe does not play any role here. Between cmd.exe and Windows Terminal there is conhost.exe (openconsole.exe), it is responsible for such handling of emoji. If we replace conhost.exe (openconsole.exe) with something of our own, then there will be the expected result
Sorry, I omitted details for the sake of brevity. Cmd.exe uses the COOKED_READ input handling provided by the Console API, and the server for that API is conhost. So yes, patching openconsole (=== conhost.exe) will fix this, and that's what the whole collection of issues is about.
Will there be support for country flags at some point?
That's outside of Terminal's control, the Segoe UI Emoji font just doesn't include flags.
Has anyone here tried to edit the Segoe UI Emoji font file and add in / replace the country flag emojis from another font? The Terminal doesn't support images so printing out GIFs or SVGs is a non-starter.
When will we get Nerd Font Icons(Glyphs) support in conhost.exe?
When will we get Nerd Font Icons(Glyphs) support in conhost.exe?
You should be able to install a "nerd font" font and set it as your font today. Also last year, and perhaps some years prior to that one.
With #16916 merged and with all the work that led up to it, support for complex Unicode, including Emoji, is effectively done. There are some smaller issues left to clean up, but I expect them to be a rare encounter. As such I'll close this issue for now.
This will ship in Windows Terminal 1.22 this year. If you want to try it out right now, please feel free to download our Canary (nightly) build here: https://github.com/microsoft/terminal/discussions/16121
Please note that PowerShell does not have support for complex Unicode yet, but that's expected to change in the foreseeable future (no exact date yet).
I'll keep this issue locked since a lot of people are subscribed to it and would get notifications every time someone posts here. If you find any issues with our implementation, please report a new issue. If you have any other feedback, please feel free to start a new discussion.
Please support emoji within Windows Console.
Very useful when you code in
vim
newsletters for startups or when you categorize stuff by emoji.Maintainer notes: