microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.02k stars 8.23k forks source link

Add emoji support to Windows Console #190

Closed HLFH closed 2 months ago

HLFH commented 6 years ago

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:

### Input
- [ ] #1503
- [ ] #7777
### Output
- [ ] #8000
- [ ] #1472
AmericanY commented 4 years ago

@DHowett-MSFT that's happens on CMD, PowerShell and windows new terminal .

Vikr-182 commented 4 years ago

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 image

DHowett-MSFT commented 4 years ago

I just want to say, with apologies, that this looks hilarious.

luke1961 commented 4 years ago

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.

fcharlie commented 4 years ago

@luke1961 see https://github.com/fcharlie/bela/blob/master/test/fmt/main.cc

luke1961 commented 4 years ago

Thanks!

remidebette commented 4 years ago

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 ?

image

Windows Terminal Powershell Core 6.2.1 Meslo LG M for Powerline

am11 commented 4 years ago

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

zadjii-msft commented 4 years ago

@remidebette You'll want to see #1503

remidebette commented 4 years ago

@zadjii-msft , this seems quite hard, but will be really nice once you crack it. Hang in there!

gund commented 4 years ago

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

adiviness commented 4 years ago

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.

louanfontenele commented 4 years ago

How can i fix the emoji?

herbhuang commented 4 years ago

I'm encountering the same problem; it seems no an up-to-date solution afaik.

image

schuelermine commented 4 years ago

Sweet! Another use case: I have a command line app that outputs warnings using ⚠.

Output of Emoji works fine in my experience.

Raibows commented 4 years ago

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.

  1. Git Bash GUI pic08-27-12-45-00
  2. Git Bash with Windows Terminal pic08-27-12-46-35

My windows terminal version is 1.1.2233.0. Hope could fix it as soon as possible! 👍 And is there an estimated schedule?

DHowett commented 4 years ago

Please file a separate bug for this issue and include the contents of your Windows Terminal settings file.

mamayadi commented 3 years ago

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

rymnc commented 3 years ago

Emoji's dont show up in an ssh session as well, not sure if you know about it.

thiagocavalcanti commented 3 years ago

Any update on this?

zadjii-msft commented 3 years ago

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? image That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

Codingpowerx commented 3 years ago

Emojis😊😋🥵 works very well on VS CODE Terminal!

miniksa commented 3 years ago

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.

lloydjatkinson commented 2 years ago

Is this still on the backlog? Unicode 13 was released in March 2020...

paul-at commented 2 years ago

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.

brupelo commented 1 year ago

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:

image

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!

zadjii-msft commented 1 year ago

To clarify:

This has kinda become the mega thread for both, though, most of the remaining work remains in #7777.

brupelo commented 1 year ago

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

WindowsTerminal_2022-12-18_15-33-43

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

zadjii-msft commented 1 year ago

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

o-sdn-o commented 1 year ago

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

https://user-images.githubusercontent.com/11535558/210380863-d8061bd5-c4e0-4a3a-963f-cb245e8e845b.mp4

zadjii-msft commented 1 year ago

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.

marklit commented 1 year ago

Will there be support for country flags at some point?

image

TheDecryptor commented 1 year ago

That's outside of Terminal's control, the Segoe UI Emoji font just doesn't include flags.

2664 would allow customising the fonts Terminal tries to use, you could then include something like "Noto Color Emoji", which does include graphical flags.

marklit commented 1 year ago

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.

Welding-Torch commented 5 months ago

When will we get Nerd Font Icons(Glyphs) support in conhost.exe?

DHowett commented 5 months ago

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.

lhecker commented 2 months ago

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.